[cowiki-dev] Re: CoWiki File uploads, downloads
PAUL HANCHETT <[email protected]>
| Newsgroups | gmane.comp.php.cowiki.devel |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]
> <mailto:[email protected]>>
>
>
> 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 :)