Quote:
Originally Posted by tompe
Well, for an open source project one use of it is to reuse the code. Only seeing code reuse as a convenience for the developer is a mistake.
|
And where is a user going to encounter source code? Most non-developers don't care, and those that do, frankly, you should watch carefully (either they lied and really are developers, or they're apt to break something).
Back to the original point I was trying to make, which is why I think the choice of canonical format being epub is immaterial -- I've rethought, and I agree that it *is* important. It's important in the sense that I think it would be *better* to use a new format. The reason I think this way is to ensure freedom to extend the system.
Let's say they did use epub internally. This means there are going to be dependencies in a variety of places:
- parsers/generators of other (non-epub) formats;
- the application's manipulation of the internal (epub) document
Let's say further that a new format comes out, very compelling, that includes support for animated vector graphics (probably *not* on a PRS-505). They now have (assuming epub doesn't have animated vector graphics -- if it does I'm impressed) a rather *painful* opportunity to add support for this format without a rearchitecture of the system. They at least have to branch off of epub, and deal with any breakages, on a piece of software that has, for all intents, shipped.
Consider instead that from the beginning they anticipate this possibility, and instead branched off of some format, or created their own, before all these dependencies were established. Then, they can have the following model:
(Editor) -> (canonical document) <-> (document-foo translator) <-> (foo-file parser/generator)
If a new file format foo2 comes out, they just add the parser/generator to convert, say, foo2 to their canonical form. If foo3 comes out and requires extending their canonical model and adding editor support, they can do so without impacting any of the other translators. The file parsers are never impacted, since they translate to fixed forms. Just add some metadata to the formats to list their feature support, and they can detect whether you'll lose formatting at all going from one type to another.
So this leads to the idea that the canonical form, whatever it is, should be entirely under our control. They should own it, it should be theirs free to modify. In exchange, they offer the ability to export to a variety of formats, potentially losing formatting that isn't supported at the destination.
The canonical form could be a true *branch* of epub, but it should *not* be epub itself.