logo       
Google Custom Search
    AddThis Social Bookmark Button
-->

[cowiki-dev] Re: CoWiki File uploads, downloads: msg#00016

Subject: [cowiki-dev] Re: CoWiki File uploads, downloads
Szilard,

I envision several use cases for users:
  • I want to embed an image or other object (like a script of applet) into a coWiki page for display.  The embed plugin sort of does this in a limited way.
  • I have a page, or a collection of (html) pages and images that I want to display as part of the coWiki installation.  (As an example, the documentation pages generated by Doxygen.)  I don't want to have to use a separate web server to deliver these pages!
  • Let users download the current version of a document via the browser (much like you suggest below).  Twiki has an implementation of this we can use as a model.  Again, I don't want to require a separate web server.
This implies some needs for authors:
  • Upload a document or object for display embedded in a coWiki page.   (Implies serve uploaded document as need for display in a coWiki page)
  • Upload (and download?) a tree of directories and content.  Inter-document references must look like normal http file links!  Need to also maintain coWiki security for consistency.  (Also implies serve these documents.)
  • Upload (and track changes to) a document provided for later download.  Ability to show revision history.  Advanced would allow retrieval of previous versions.  Implies serving these documents.
  • Share a common document or tree of documents between coWiki pages-- For example, showing the same graphic on multiple pages.
Does this fit with how you see things?  I couldn't quite follow your idea... 

It seems that for all of these ideas there is an upload mechanism of some sort, a way to indicate on the target page what should be referenced in the generated page, and a way of serving up the desired content to the browser.

BTW, let's talk in generalities for the moment.  Daniel is in the process of reworking the database right now and I don't want to give him fits worrying about what we are going to do!  :-)  {See Daniel I *do* care about you!}

Paul

PS -- How do you say your first name?  :)

Szilard Novaki wrote:
Hi Paul,

I'm happy that you also want the feature. First, lets discuss about the feature, without thinking about the solution:

I'd like to have something, lets call it "downloadable", which is not displayed by the system, but served by the server based on its mime type. It should integrate seamlessly in cowiki architecture, i.e. "downloadable" should be created, edited (updated) by users, it should be version managed. Users may wish to place references on that documents, e.g.:

-- DOC

You can download version 1.0 .tar.gz release ((Downloads|v1.0)(here).

-- /DOC

After this document is saved, there is a link on "here" and it is served based on its mime type (application/x-gzip), it is not displayed.

Ok, if we agree on the feature, I get confused, when I think of implementation:
- Normal documents are editable, because those can be displayed (cowiki prints edit link, when displayed)
- How can downloadables be edited, if they get downloaded immediately?

Maybe, we should extend the grammar:

-- DOC

You can download version 1.0 .tar.gz release [[Downloads|v1.0][here].

-- /DOC

This is a new link type, that means, that the referenced document is not displayed, it is served instead, based on it mime type. If a "downloadable" is referenced with ()() structure, then it is displayed like this:

This is a downloadable document. Click here(link) to download it.

In this case, the downloadable can be edited, as it is displayed (we have the edit link).

Maybe I got too far, please ignore the solution part if you not agree with the feature part :)

--
Szilard Novaki <novaki@xxxxxxxxxxxxxxxxxx>


p.s. I would be happy to join the development team. I think we should make that step when I make my first contribution. Hopefully, that will happen soon :)
<Prev in Thread] Current Thread [Next in Thread>