Re: Commit: date field


Subject: Re: Commit: date field
From: Paul Rohr (paul@abisource.com)
Date: Fri Feb 16 2001 - 20:32:11 CST


At 09:02 PM 2/16/01 -0500, Dom Lachowicz wrote:
>I actually have MSWord fields importing just fine right now. I don't know
>much about RTF fields, however.

The current approach is thinkable for importing small, unformatted fields.
However, it's not likely to scale well. You start hitting rough spots when
exporting, especially when trying to round-trip unrecognized field types.

By the time you start dealing with the fact that both RTF and Word also use
the fields concept for regenerating large hunks of formatted content in the
document, you realize that a totally different approach is needed.

At first, I wasted a lot of time trying to find a logical cleavage point
between the two models: ie, some simple fields use the current model, and
others use a more complex one. Yet the more I delved into it the clearer
the answer got -- use the same model for both.

>>Thus, I should ask -- if I invest the time needed to revive all my design
>>notes on what those more extensive changes would entail, would there be
>>anyone able to do anything with them?
>
>Please do.

Gulp. I'll try to have a talk with my spouse this weekend to see if this is
feasible. She'd have my head if I did the design work now and it didn't get
used, though.

>Both ideas make me cringe. The options really are:
>1) Redesign fields after 1.0 and introduce incompatible changes to the file
>format (but that's partially why we change major version numbers, isn't
>it?).

Yes, but it also means that we effectively force our entire userbase to
upgrade away from stable 1.0 builds into unstable 1.1 builds as soon as the
new content starts getting deployed. Indeed, if we're sure we're heading in
this direction, we probably need 1.0 to refuse to even try to read stuff
from later file formats, because it's a likely cause of crashes.

There's no getting around the fact that the choice of field mechanisms is a
fundamental design feature of any word processing file format.

>2) Break it now and in doing so, break all of the existing documents

Sure, but we're not at 1.0 yet, and the numbers of documents involved are
much, much smaller than they will be in the post-1.0 world. Even better --
anyone who's willing to play with pre-0.9 software should be willing to run
a fairly simple conversion script on their documents.

>I'm leaning toward doing #1 rather than #2, and it appears that your
>feelings are the opposite. I'm flexible, though.

Good summary. I want to be inflexible, but I can't afford the time to fix
it all myself. :-)

Paul



This archive was generated by hypermail 2b25 : Fri Feb 16 2001 - 21:16:54 CST