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