On Sun, Feb 05, 2012 at 11:26:44AM -0800, don kretz wrote:
Greg, do you have any kind of formal or semi-formal conceptual model of the domain we're dealing with here?
Something like an Object Model in object-oriented software terms; or more obscurely but perhaps a better fit, Object Role Modeling?
I don't, but if you point me at an example conceptual model for something else, which you think is useful, I can try to come up with something similar. Part of why I didn't start with a requirements list is that my current approach is to look for existing capable software that does a good portion of what we need. No such software will be complete to all our desires, but it should be a good start. This is to avoid writing our own tools from scratch, which (as capable as we collectively are at such things) leads to problems in maintainability and portability. The basic feature list we'll need for a complete tool is fairly short, and might build upon multiple existing tools: - able to authenticate users - able to handle different user authorizations, at grainularity finer than "whole site" (i.e., someone might be committer for one eBook, but not all eBooks) - can display differences, merge trivial results, handle forks, and similar source code revision practices - keeps history; can display older versions of files - can be plugged into a transformation system - can use structured metadata (DC, XML, MARC...) to populate information about books - can handle our 38,000 titles in ~1.5M files - can handle books (i.e., "projects") with multiple source files, as is found in HTML+images - a documented API - can work with multiple file types Conceptual versus functional requirements: - well documented in English - runs on a Linux server - active development community - open source - able to accept code contributions, track feature requests, etc. I would add these as desirable, but not critical: - exposes the back-end filesystem, for use with other tools - some sort of rating system for most popular items (or, if not, it is required that we can build one upon the tool) - integrate wiki or bug tracking or other features in support of the effort This is just a quick listing, and is probably not complete. My inclination is to choose a capable and flexible tool (or multiple tools) as the basis for our work, then use our skills to build upon it, perhaps integrating additional existing tools. Such tools come at different levels of sophistication. Base level tools include mercurial/git/svn. Mid-level tools include Wordpress, Django. Higher level tools include TRAC, Notre DAM, ResourceSpace, Sourceforge, DSpace... I am, of course, quite interested in having an exit path from any selected tools. We don't want to be stuck, if our choice turns out to be limiting us in a few years. -- Greg
On Sun, Feb 5, 2012 at 11:13 AM, Greg Newby <gbnewby@pglaf.org> wrote:
On Sun, Feb 05, 2012 at 01:36:20PM +0100, Jeroen Hellingman wrote:
Quite an odd-beast, but why not consider fossil?
(http://fossil-scm.org/index.html/doc/trunk/www/index.wiki)
Stand-alone, integrates everything, and could be used on a book-by-book base...
There are some super features in that package. I never looked at it before.
Some shortcomings/drawbacks I noted: - filenames are lost, so we'd need an additional layer to map updated files into the collection our readers see and download from (fossil names all files by hashes, and mixes "source" with wiki, bug tracking, etc.)
- single maintainer, seems like (though with some additional contributors, and an opening for us to join as contributors), putting some risk of abandonment
- user control seems simplistic, and possibly not amenable to the hierarchy/meritrocracy approach to "who can commit".
A challenge that many such solutions will have for us is whether to treat each book as a "project," or the whole collection. I am leaning towards each book as a project, but that only works if we can easily share/inherit from existing books. That is, nobody is going to use a Web UI to set up 38K projects to "seed" our efforts.
Anyway, this does look good, but I saw some limitations.
-- Greg
On 2012-02-05 09:56, Greg Newby wrote:
I'm still pursuing the theme of an existing sophisticated code base to enable supporting multiple versions & formats of our eBooks (user-contributed, curated, edited, masters and revisions).
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d