Re: [cowiki-dev] HTML & Embedded Images

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.