Re: [cowiki-dev] HTML & Embedded Images
Paul Hanchett <[email protected]> Fri, 15 Jul 2005 20:05:53 -0700
| Newsgroups | gmane.comp.php.cowiki.devel |
|---|---|
| Message-ID | <[email protected]> |
Just to add a note of reality-- I don't much care how they are stored, that can always change. Right now we lack the infrastructure in code to do /anything/ useful in this regard. :-( Sy wrote: >One advantage of having media file stored on disk is that an external >processor can be used to generate thumbnails or resize a picture for >different uses.. etc. > >The same could go for allowing an archived document or set of >documents to be downloadable as a .zip or .tar.gz or .tar.bz2 etc.. >converted on the fly (and cached for later use). If the binary is >stuck in a table, it makes life more complecated. > > > >On 7/11/05, John (yt) Hogenmiller <[email protected]> wrote: > > >>I've been thinking about this and I was thinking that a few things >>would be nice to have available in the cowiki package. I'm not >>putting these as feature requests because I figured they're somewhat >>covered, and this is more of a discussion thing. This is all based >>off of previous conversations on the list. >> >>1) an http accessible interface to the cowiki parser. Whereas >>currently, the template calls a plugin to retrieve a specific >>document/node and parse it, what if there was a "seperate" php script >>that given a node *name* could retrieve that node and display it >>without the surrounding "theme" stuff. Granted, it would have to read >>session variables and what not to know if the current user has >>legitimate access to said node. This is more for future use when we >>start doing things with js. Basically, having some nodes of >>user-editable documentation included in the database (taking great >>care during upgrade situations to prevent overwriting any existing >>nodes of similiar documentation) that some js/xml/rpc magic could >>retrieve on the fly and display in a floating layer is "good stuff". >> >>2) Either: >> a) A "seperate" file manager. Using our existing access scheme, >>allow people to upload media into the webserver via http post. There >>are already existing GPL web-based file managers out there, we could >>choose the best and integrate it, or provide a modified version as an >>optional add-on to cowiki. The embed plugin could take an unresolved >>link and take you to an somewhat pre-filled out upload form on the >>file manager. >> >>-or- >>b) Add a files table to the database and use some of the common >>methods for storing binary files in a mysql table. While I don't know >>how practical this is, especially with larger files, I know it's been >>done many times before. A practical upshoot to this approach is that >>binary files could receive the same permissions set as the document >>nodes. >> >>-or- >>c) A combination of the two.. Use a home-brew web based file manager >>to manage the uploading/renaming/deleting of files on the server in a >>specific, restricted directory, but also maintain a database table >>listing the files uploaded and use the same permission set as the >>regular document nodes do. >> >>3) A plugin that can retrieve an external html file. Embed doesn't do >>this, but it would be pretty simple to implement, and it would allow >>people that need to put some fancy pages in place the ability to do >>so, especially if implemented alongside #2 above. >> >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] > > > >