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]
>
>
>  
>