[Clipart] DMS development needs

[Bryce Harrington]

Hi all,

One of the things that struck me in the emails over the past couple of
weeks is that a number of people have a desire to work on DMS, but are
unsure of what to do.

Over the next couple weeks I'm going to make an effort to explain the
needs and plans, with the hope that maybe it'll help people gain
certainty over what can be done.

So far, my intention has been to do all the work myself.  I know I can
do it, given enough time, and I'm certainly dedicated to seeing it
through, even if it takes a long, long time.  The design is clear, it's
just a matter of time to implement it all.

Yet, I also know that we've got some good coders in this project, and
with even just a little time from one or two good hackers, development
could be greatly accelerated.

Anyway, if it turns out no one has the time or inclination to work on
it, that's fine, it'll still get done eventually.  But if you do have
a few hours to put in, and feel the motivation to get it in place, you
may be able to make a huge difference.


First, a bit of background.

DMS takes a different approach to "service" than your typical LAMP
application.  Actually, it's quite old school - it dispenses with a
database in favor of reliance on the file-system, as email, web, and
many other unix servers do.  DMS's goal is to be the analogy of
something really low level, like postfix or apache, and leave interface
level work to other things.  "Do one thing, and do it well."

Most of the basic operations in DMS are implemented, including check-in,
check-out, listing, and updating.  A number of features still need
implemented, including searching and so forth, but the infrastructure is
in place to the point that I think these will be straightforward to add.
I can explain the plans for these in more detail later if anyone's
interested.

It's at the interface layer where work is needed right now.  I've
written some commandline tools that work with the NFS server to do
document upload, listing, and retrieval, and to list the metadata for a
file.  What we need next, though, is to create web versions of these
tools.

Initially, I'd thought we'd just do them in PHP, however there's an
incompatibility between Perl's SOAP and PHP's SOAP that is a roadblock
for this.  Thus, I think this would be best implemented as a CGI.

I've recently learned of "CGI::Builder", a module that makes creating
CGI's quite easy.  I've done some experimenting with this, along with
its Template::Toolkit extension, and created a prototype using it,
called dms-client-cgi.  It is in the OpenClipArt CVS, and I would
encourage you to check it out.

You will see in the tm/ subdirectory are a set of templates.  Each of
these corresponds to a web page in the application.  The "fill in"
sections are denoted with [% varname %].  When run, the web app will
fill in those variables with the appropriate value.

The code itself is implemented in the Document::CgiApp module.  
I wrote this pretty much straight from reading the CGI::Builder man page
(which is very thorough and has good examples.)  Expect to hear me
expound on this a bit more in the coming weeks.

Anyway, what I think needs to be done next, is to take the SOAP::Lite
code from the shell scripts I made, and weave that logic into the
templates and code in dms-client-cgi.  I think this will require a bit
of experimentation to get the syntax right and pinch out bugs, but
technically should be totally doable.  It may seem a tad more cumbersome
than PHP, but I think if done right, this idea of separating the code
logic (Perl) from the display logic (HTML) will make a much, much more
maintainable end result.

More to come...

Bryce