[Clipart] dms status

[Bryce Harrington]

Hi all,

Tobias asked me to write a summary of where things are with dms, what
needs to be worked on, etc.

As a quick recap, the architecture for dms involves a daemon that runs
on the server and provides a SOAP API that remote scripts and tools can
use to interact with the document system.  The daemon is composed of a
short SOAP daemon script, that simply directs calls to a perl module
called Document::Manager.  Document::Manager provides a set of routines
for checking documents in and out, adding properties, querying for lists
of things in different ways (author stats, system stats, change history,
etc.)  

It also allows retrieval of a Document::Object which provides detailed
access to the document in question, including metadata, comments,
workflow state, etc.  A 'Document' is a collection of one or more files;
for instance, this could include an SVG file, a thumbnail png, a
metadata xml file, and a log of discussion about it (imagine something
like an mbox file).

Document::Manager works through a lower level module called
Document::Repository, that handles the actual storage and retrieval of
information from the file system.

There is also a piece WebService::TicketAuth, which handles the
authentication of the user.  Another (TBD) piece is needed for handling
authorization (i.e., to identify if the user has administrative or just
normal access).  This was going to tie into Mantis so that we wouldn't
have to write our own account management code, but since we're not using
Mantis anymore, we'd need to figure something else out.

In theory, these modules will work with *only* the file system (i.e., no
database required), but will allow use of a database for caching
purposes.  Because the system does not rely on the existance of the
database, this means that backups or replications could be done by just
mirroring the repository filesystem itself; no database synchronization
is needed.  However, none of this db stuff is implemented yet so it's
entirely theoretical.


Prior to the freedesktop.org rebuild, I had a functional daemon
installed and running that permitted checking in documents and
retrieving them.  There were several dependencies required to be
installed to make this work, so one of the next steps would be to
re-install these and get the daemon running again.

The next item on the todo list is to implement the property handling
code.  I think I had this about half-way done when the rebuild
happened.  Basically, there just needs to be some code implemented in
Document::Object to permit storing of arbitrary properties into a file
of some sort (XML::Simple, Config::Simple, or so forth.)  Then routines
hooked up for adding a new property, editing/deleting a property, etc.
Also needed would be a way to query the repository as a whole based on
properties (e.g., select all documents where author='niku').

Once property handling is available, a whole host of things could be
implemented on top of that.  I think the most worthwhile thing to do
first would be workflow handling.  This would allow tagging a document
as to whether it is "new", "accepted", "problem", etc.  This would allow
us to track and filter for items that have copyright questions, have bad
metadata, or whatever, so they can be kept out of the releases until the
problems are resolved.

For the database side of things, the major todo item is to implement a
routine that can take a Document::Object, render its contents into SQL,
and store it.  Obviously, this also requires some SQL design; ideally
this would be done in a way that is generic such that the db schema
would not need to be customized if someone wished to use the system for
something other than SVG files.

I had assumed the system would perform fairly well even without the
database, however I've found that actually it's quite slow.  However,
there are a couple places where I took some particularly dumb design
approaches, so I think that if these were redesigned they could be much
better optimized.  (Basically, it hits the file system far too much, and
it doesn't store info in memory between calls, as it should.)

For the interface side of things, the next step is hooking up PHP to the
SOAP calls.  I had assumed this would be a no-brainer since PHP supports
SOAP.  Unfortunately, the way PHP supports SOAP is different than how
Perl does, and I found that the way I had coded Document::Manager won't
work with PHP.  This was pretty disappointing.  The two options would be
to recode OCAL's website to use Perl instead of PHP (such as through
Template Toolkit), or to recode Document::Manager into a non-OOP style
that will be compatible with PHP.  Neither solution would be much fun to
implement, and would take a good bit of time to do.  


Anyway, that's where things are at.  The freedesktop.org rebuild and the
Perl/PHP SOAP incompatibility got me off track, and things with Inkscape
such as gtkmm and the 0.40 and 0.41 releases have kept me busy since
then.  However, I'm pretty confident that the parts that have been
implemented so far are good and solid, and that the overall design
approach is right.  There's a lot left to do, though.

Hope this helps,
Bryce