[WWdevel] Re: CVS alternative

[Sam Hathaway]

On Jan 10, 2005, at 6:48 PM, Michael Gage wrote:

> On Jan 10, 2005, at 4:29 PM, Sam Hathaway wrote:
>
>> By the way, has anyone thought about how problems will be packaged? 
>> Many problems consist of more than one file and it might be worth 
>> laying out a packaging format, so that a problem and all of its 
>> auxiliary files and metadata can be distributed as a single file.
>
> This is a really good thing to look at.  I still regret that we 
> couldn't use the "resource fork" idea of mac files systems, so that a 
> problem and all of its pictures stay together.  Are there equivalent 
> schemes used on unix and windows?  What is being done on the mac these 
> days?

For distribution packaging there are many archive formats -- tar, zip, 
pkg, etc. with various features. For installed files, though, there 
isn't much. Win32 can embed certain resources (icons, for example) in 
executables and libraries. In UNIX, there's never been much of an 
attempt to do this. On OS X, of course, there are bundles.

> Our current system, which works, but is a bit fragile, is to use the 
> same name for the directory and the .pg file when packaging a file 
> with its accompanying pictures, applets or whatever.  e.g.    
> prob1/prob1.pg  accompanied by prob1/picture1.png, prob1/picture2.png, 
> etc.  We usually place applets in a common area so that they can be 
> used in multiple places, but that also means that frequently problems 
> using applets don't work when you are first setting up a course.  You 
> have to tweak the addresses in the problems and/or find the applets 
> and install them in the right place.
>
> Any ideas for making this situation more robust and straightforward?

A simple tweak would be to put the problem file in the directory with 
the auxiliary files. This sits better with me than having the problem 
file and the directory of auxiliary files side-by-side, since it would 
be harder for a problem to be separated from its auxiliary files. These 
directories could be tarred up for distribution if need be.

You mentioned the applets, and I'm thinking that it might be worth 
talking about dependancy information. Perhaps a piece of metadata about 
a problem should be a list of other resources on which it depends 
(maybe along with version ranges, if needed). The more I think about 
it, the more the needs of the problem database converge with the needs 
of operating system distribution packagers.

For example, Debian packages consist of an archive containing the 
package files and several several well-defined metadata files that give 
information about the package and its dependancies, how to build it, 
etc. To build an archive, the metadata in each package is assembled 
into a Packages.gz file that can be read by the APT system to build a 
dependancy graph, etc.

Of course, this is overkill, but what's currently proposed seems 
essentially like a simpler version of this, if you view each problem 
source file as a package, and the MySQL database as the Packages.gz 
file. It might be worth formalizing ways of tracking dependancies for 
situations where a problem depends on some external resource like an 
applet. On the other hand, it might not be worth it.

By the way, all involved with the problem database project are free to 
use the WeBWorK Wiki to share ideas and write up proposals: 
<http://devel.webwork.rochester.edu/>.
-sam