Subject: one more try on fields design
From: Paul Rohr (paul@abisource.com)
Date: Tue Sep 26 2000 - 19:54:44 CDT
I have to say how much I admire Martin's willingness to hack through Keith's
patch to try to make it "good enough" for use to use *now*, and having
running code is a wonderful thing.
Clearly Martin is much more conversant than I am with the intricacies of
that code, so I'm not going to try to keep up with him there. (Australia's
a long way to go to swap baby sitting time for coding time.)
However, since we seem to be at odds about the intended scope of the work
needed for fields, I figured it was worth one last attempt to explain why
I've been focusing on the design issues I've been flooding the list with.
My goal has been to come up with a design that I'm confident will allow us
to handle most or all of the fields specified in RTF. I've been
particularly concerned about coming up with a mechanism that's robust enough
to handle:
- lossless import/export to/from from RTF, Word, et al
- subtle interactions between editing, updating, and undo
- avoiding future headaches with file format compatibility
Thus, I'm tackling things from the other end, looking out for future gotchas
and trying to avoid them.
Thanks to Martin's insistent prodding, I've done some more digging and have
come to the following conclusions, stated as assertions:
1. *all* fields should be implemented as chunks
2. field updates are rare (and undoable)
3. field edits are always undoable, too
4. headers are a special case
Since my assertions alone are unlikely to be compelling, I'll start sending
separate emails in a minute with further details on each.
Paul
PS: In the mean time, I should note that I think that the final result will
not be all *that* much different than what Keith's already done.
This archive was generated by hypermail 2b25 : Tue Sep 26 2000 - 19:48:21 CDT