greg said:
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).
you don't need a system to handle "user-contributed revisions". because you don't need any "user-contributed revisions" at all. that'll just add more "snowflakes" to the avalanche burying you. what you need is very simple. you need to _improve_ your converter routines with a few small changes that'll immediately end 85% of the complaints you get. this is the equivalent of clearing airways and stopping bleeding. then you need to apply some elbow grease to fix the remaining glitches, in the derivatives, and curtail regenerating any of 'em, so as not to rewrite over the fixes which you just had to apply. this is the equivalent of controlling for shock; quite important. then you need to re-do the _input_ for those problem-children, so you can resume the regeneration at the earliest opportunity. this is the equivalent of making splints for all the broken bones. finally, you need to test all new submissions, to make sure that you are not allowing any new problem-children to be admitted. this is the equivalent of protecting the patient from new injury. eventually you will offer a handful of formats for every book -- such as plain-text, .html, .mobi, .kf8, .epub, nook, and ibooks. (yes, nook and ibooks officially use .epub, but you'll be able to create versions of an .epub file specially customized for them.) and none of the formats will need to be "generated" on-the-fly. they will all exist as solid versions, both known and dependable. the only time you will regenerate them is when you fix an error. and way far down the line, you'll be able to customize output to individual preferences, but walk first, before you go tryin' to run. because today, you've got broken bones throughout your body... -bowerbird