[cowiki-dev] How to improve coWiki with a media document management system?

How to improve coWiki with a media document management system?
--------------------------------------------------------------

I already mentioned a few times that I had the idea of how to include a
media managemement system to coWiki. This idea was one of the first we had
implemented in the very early versions of coWiki in 2002. Andreas Seebald, a
co-worker of mine was pragmatic and wrote some - then it was weird - stuff
to manage this. But it basically worked and was enough for the task then.
Just an upload, just a display.

But the coWiki became more mature and got access permissions. And thats the
point: access permissions - hierarchical. Having special permissions to any
media like to the usual coWiki documents or directories, changes much and
lets the whole experiment to seem as "complicated" as the normal restricted
management of documents already is.

I talk about "media". What is this?

From an old request of discussion on develnet.org:

    Let us define "media" as every file type that can be embedded in a HTML
    document: GIF, JPEG, PNG, PDF or movies and streams of any kind. An easy
    access to a comfortable (kind of "gallery") area would enrich the whole
    application.
    
    Media management can be done with a few plugins that play together and
    with small changes in the controller (index) file.
    
    The goal
    
     * Very easy media browsing
     * Uploading and resizing (for the files types where appropriate)
     * Searching for media documents by name and keywords
     * Crossbrowser functionality (note: object <-> embed etc.)
     * Hierachical structure and ...
     * ... restricted and confidential access to media elements
    
     * Embedding media files in coWiki documents should need a
       plugin call only.

(Normal ASCII texts or HTML are also included!)
       
Well, placing media in coWiki documents seems easy, just write a small
plugin like the <plugin embed> and let it fetch and show the content,
regardless if it's an image, a .SWF file .. or PDF or anything a browser is
able to display.

Fortunately, I was not so naive, to expect to rewrite similar tasks that I
had in mind, but prepared coWiki to manage also other directory/document
structures with restrictions: almost all the critical tree composite classes
for the management of confidential media are there. 

/We only need to look at "media" and its categories like at the directories
and documents of coWiki/.

Instead of writing a coWiki text document, one will upload a file - with his
permissions that are exactly the permission for a document. The uploader is
able to change the "media" -or- anything he uploaded (guest-behaviour), like
he would be able to change any coWiki document he created.

How? <plugin media>. This plugin, if it has not an "id='n'" defined will
behave like a not existing coWiki document. It will display a dummy image or
a similar thing one can click on. Then it's the magic part to display: a
fully functional document management system.

After the magic is finished, and the user has chosen a "media" file, the id
of this file is assigned to the <plugin media> that called it (yes it is
possible): the result might look like <plugin media id="1234">. From now on
the media plugin will display the "something". An additional parameter like
<plugin media id="1234" linkonly="yes"> or similar wouldn't display the
media file, but provide a link only. This makes sense if I want to add a few
attachments to a document that shouldn't be displayed directly, e.g. a bunch
of PDF documents.

Wait, what did I ment by "the id of a file"? Likewise the coWiki documents
have ids (primary keys) in the database, all media files would need to have
them too. Due to the permission and access checks any "media" will need to
be passed through a single controller file that checks the permissions - for
normal document files its the "index.html" controller, for media it would be
e.g. "media.php". This is not the fastest way to pass e.g. images through
the webserver, but somewhere the permission checks need to be made.

In the core.conf there is already a path defintion where to put the uploaded
files: [PATH] BINARY.

There is one thing that might not be so clear for the media management if we
compare it with simple document management. The media files would need to be
more categorized, moved, managed. This all is also true for all coWiki
documents and hence we will need also the possibility to move the documents
around (ACID transactions needed!). I have a prototype here that almost
solves this task, but can't use it until I can make sure that a rollback on
the database does what I expect from it.

What we miss, for documents and directories and also media, is a kind of
"chown", "chgrp" or "chmod" - and to make sure that works we need ACID
transactions.

What I have in mind is, that clicking on an not existing media plugin, an
other display loads that could look like:

--------------------------------------------------------------------------
- here               | Here I can manage, move etc. my "media"
  - is               |
    - a              |
     - tree          | and if I've chosen it/them, I can take 
                     | over selected items. Maybe move them to categories,
- similar            | search, chown, chgrp etc.
  - to the document  |
   - directory       |
  - structure        |
--------------------------------------------------------------------------

Maybe you want to take a look at one of my other projects at
<http://demo.vividsites.de/> .. 
     
I am sure I forgot something here, ideas and code are welcome. But PLEASE do
not start blindly! This need to be deliberated.

regards dtg