greg said:
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
and then, for good measure:
This is just a quick listing, and is probably not complete.
wow. yagni. yagni, yagni, yagni. you ain't gonna need it. period. good thing too, because the complexity of it would bury you. it amazes me how you can take something that is _so_simple_ and infest it so fully with such a confusing mess of complexity. here's a copy of pride and prejudice.
as you probably know, it's a pretty popular book. it's been considered to be a classic for some time now, and i know it must get a lot of downloads, from all of the e-book websites. and it's really simple. as you can see. plus, it ain't gonna change. not too much anyway, not in the near future, or the distant future. now, there might be errors in this, but -- once you found 'em -- pointing to them would be a pretty simple matter, and then the correction procedure would also be a very straightforward thing. here's a plain-text version:
as you might imagine, i generated the .html version, up above, from this .zml file. it was easy. really easy. because there is very little markup required by this book... _remarkably_ little... like any typical book, it consists mostly of plain old paragraphs. there are some italics sprinkled about. and some blockquotes... and then of course there are the chapter-headers -- 61 of them. and the title-page and table-of-contents required some markup. and a few small-caps, which i discarded as "decorative" elements. but that's it. so this is another "baby" book, like the ones jim did, which requires almost no markup at all. so it's just a bit _ironic_ that marcello used this book to demonstrate his markup prowess. i can't imagine any reason in the world why you might think that you would require some kind of complex system to "handle" this. you put 'em on a web-page, and that's pretty much the end of it. you'd want to put up some other copies of it as well, for users... like an .epub version, and a .mobi version, and a .pdf, and so on. like i just posted in the a-b-c's of first-aid for project gutenberg. and "the crap formats you serve". and a million other prior posts. and i could use the plain-text version to generate those formats, with a click of one button, using some simple conversion routines which i programmed myself... and marcello will be all to happy to inform you what a crappy programmer i am. yet... i made it work. and you can do the same thing with 94% of the books in your library. and probably more, but percentagewise, let's start with the first 94... that's if you do what needs to be done. but if you keep wasting your time and energy on fantasy schemes for some "sophisticated system" promising to do a bunch of crap you don't even need to do, then you won't get a damn thing done. and you know what's funny? :+) what's funny is that you're gonna choose the stupid path. again. yagni. yagni, yagni, yagni. you ain't gonna need it. you ain't... -bowerbird