view release on metacpan or  search on metacpan

doc/CONCEPT  view on Meta::CPAN

Date: Wed, 11 Aug 2004 11:00:58 -0700 (PDT)
From: Bryce Harrington <bryce@bryceharrington.org>
To: Nicu Buculei <nicu@apsro.com>
Cc: clipart-list <clipart@freedesktop.org>
Subject: Re: [Clipart] Open Clip Art Library Release 0.05

    [ The following text is in the "ISO-8859-1" character set. ]
    [ Your display is set for the "US-ASCII" character set.  ]
    [ Some characters may be displayed incorrectly. ]

On Wed, 11 Aug 2004, Nicu Buculei wrote:
> Alberto Simues wrote:
> > We really need to create a repository for all the clipart, where we
> > can work together on it, as adding metadata and such. A CVS
> > repository would be very, very nice.
>
> i believe a web interface would be nicer - probably a solution could
> be a script derived from upload_svg.cgi for editing metadata

I had attempted to do a CVS repository for the clipart really early on
(the module's still there if anyone wants to use it.)  But in playing
with it and thinking about it, CVS seems too limited for our needs.

First, it has a file hierarchy approach to storing things, whereas what
we really want is a flat storage with metadata to do querying.  Second,
CVS is hard to use programmatically because it doesn't have an API, so
you have to parse stdout (I have done this in another project and it's a
pain in the neck) to get your error codes.  Third, creating a web
interface to CVS is quite hard - this is why the available interfaces
are read-only.  Fourth, while we can use CVS ok, most ordinary users
(esp. artists) will find it too technical, so you have to develop an
interface.   Fifth, imagine doing a CVS checkout after we've been at
this a few years and have gained tens of thousands of images.  Ack!

But, it's definitely true that we need a repository for this.  Our
current system is hindering each of us.  My release tools have to have a
lot more smarts in them than they should, and end up having to do a lot
of re-work on files to revalidate, etc. etc.  We run into issues
updating the browsing tool each time we do a release.  We find ourselves
having to put a surprising amount of intelligence directly into the
upload tool to compensate.

There are other version control systems besides CVS, such as subversion,
arch, etc.  However, while these correct some of CVS' deficiencies,
they're all still _source code_ repositories.  They lack some of the
functions you'd want from a DMS, so we'd still need to work around
that.  Plus, they tend to be a little more complex, and definitely don't
simplify the amount that the user would need to learn.

Looking at proper document management systems, there are a few out
there, however most are web-only (via php or similar), so they don't
give enough API-level access.

Anyway, for our purposes, I think that the functionality we require is
not so complex that we could not write our own.  Essentially we need to
be able to check documents in and out, lock docs for a particular owner,
assign document id's, query based on metadata (date, validation status,
author, category, etc.), and alter metadata (such as categories).

I've made a first pass at a DMS perl module called Document::Manager:

    http://cpan.uwinnipeg.ca/htdocs/dms/Manager.html

The idea here is to do provide the really core operations for a DMS.