[Clipart] Update Packages

[Jon Phillips]

On Tue, 2005-04-19 at 11:20 -0700, Bryce Harrington wrote:
> On Tue, Apr 19, 2005 at 01:40:48PM -0400, Nathan Eady wrote:
> > >>I have thought about this, but this may be the first time it has been
> > >>brought up on the list.  The main problem I see is with the logistics
> > >>of how the user would merge the updates into the previously-downloaded
> > >>release.
> > 
> > Of course, if there were an unpackaging tool familiar with the
> > particulars of the package format, it could handle that, but I
> > think for the moment we have to assume such a thing is future;
> > right now, I think anything we release needs to be usable as
> > it stands.  So, how would the user go about merging the updates?
> 
> >From a larger viewpoint, you could also consider the case of
> non-openclipart clipart being added.  That might suggest installing each
> update to a separate tree.  E.g.:
> 
>  /usr/share/clipart/openclipart-0.12/
>                     openclipart-0.13-update/
> 		    openclipart-0.14-update/
> 		    OOo-clipart-1.00/
> 		    bobs-clipart-pack-0.1/
> 		    etc.
> 
> Then have the "merging" be performed by the userland tool, or through
> some intermediary service provisioning tool like is done for fonts.

Right, however we should also consider that fonts are not updated
monthly. Also, I'm not sure, but think that fonts are probably
overwritten with a respective system's font package update. Do we want
to keep older versions of artwork, or when an author updates his/her
clip art, when a user updates, should that new version overwrite/merge
with the old? Also, shouldn't all versions of an artwork be accessible?
The great thing about SVG is that it is a text file, so can deal with
diffs well...yeah!

> 
> The above idea sort of defines the problem in terms of package
> management.  Make each update a separate package, then it can be
> installed and managed just like any other package.

> 
> You could also redefine the problem to be one of file sharing, and then
> look at what sorts of file sharing technologies it'd fit into.  For
> instance, it would be slick if instead of installing a huge clipart
> package, if I could simply run a program that sets up and manages a
> clipart index with thumbnails, that my drawing tools could use, and then
> when I select a file, it transparently downloads it from a remote mirror
> somewhere and caches it on my system.  This might be more technically
> complex, and is less fail-safe than the package approach, but has an
> advantage for the user in that their collection would always be up to
> date.  In theory, this same system could be used for contributing images
> back into the library.

I think this on-line approach is the best long-term solution, however,
the idea of having a space for clipart releases that are new, or updates
is interesting. Also, this could be a place that is default so that once
we start building packages on demand, then they could be stored in this
location as well. We need to start a wiki page on this (and over the
last week every time I think that I'm offline on an airplane typing...).

In the modern sense, packages are kind of the standard approach for
software that is more contained in terms of size. We don't have to think
of clip art as a standard software package. Obviously, we are
distributing graphical media rather than software source code or binary
executables, so I think it good that we think out of the box more about
solutions like this m

> 
> Another way to redefine the problem is as a version control system.
> Instead of packages, we'd have an open repository that contains the
> files.  The user would run a command to check out a copy of the repo,
> and periodically run an update command to resync it with the master.

I like this approach because it considers the past versions explicitly.
think about when an author updates their artwork, yet previous versions
were just as viable and possibly of different design. A question I have
is would the old artwork stay on the system and the updated one made
part of the new ocal release? Also, this version control system would
have to deal with lots of files in the future, and might not be as good
as having an updated index that user's can browse and select on demand
images they want, with whatever version of the image they would like.

If we went with this version control system approach, then we should
consider how to mesh this idea with the on-line system so that a user
can have a CLI client and then hopefully get some of these hot to trot
developers to make a nice GUI for it. However, this is after deciding on
an approach.


> 
> There's pros and cons to each of these approaches, and a lot of things
> to consider:
> 
>    * Will it encourage and enable increased contributions by the users?

Right, we want to make sure that whatever system we build or use, that
it allows multiple front-ends, or at least one easy to use good one. I
think though some type of CLI and GUI-based client would be good similar
to the old Ximian red carpet's RUG CLI and then the Red Carpet GUI tool.
These programs are a good model IMO for how to design a tool where the
list of imagery is synced periodically, and then a user may interface
with the OCAL repository how they want -- and also publishing this spec
would be good so that people can develop their own clients, and build
this type of OCAL browser into their apps, like Open Office, KOffice,
Inkscape, Gimp, Scribus, etc.

>    * Would it be platform limited?

Well, if we developed it as an on-line web service, or net-based
service, and published the spec, I think that way people could develop
their own interfaces for the library. That would help to make it
cross-platform. Several people have already expressed interest in
developing a client to the library, but I think this should really wait
until we have a system like this implemented.

>    * Would it be too time consuming to implement?  Or is there an app
>      that already does it that we could more or less reuse?

I'm not sure about this, but there are several good models. I think
package management apps. really provide a better template for this
functionality than how we currently distribute packages. Apt (CLI) and
Synaptic (GUI), Ximian/Novell RUG (CLI) and Red Carpet (GUI), provide
really great examples of how we can do this distribution system right. T

>    * How well would it scale?  Could it handle 10,000 users?

This is going to be interesting. I think that if we make it a service,
then handling that many users will be dependent upon server setup. At
current, fd.o has no problems distributing our content (I checked) and
is not a burden on their server system.

>    * What administrative duties will it have?

Right, hopefully an easy to use interface so that we can stay on top of
our ambitious roadmap ;)

Bryce, (or anyone) can you add these arguments to the wiki if not there
currently.

thx
Jon

-- 
Jon Phillips

USA PH 510.499.0894
jon at rejon.org
http://www.rejon.org

Inkscape (http://inkscape.org)
Open Clip Art Library (www.openclipart.org)
CVS Book (http://cvsbook.ucsd.edu)
Scale Journal (http://scale.ucsd.edu)