From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Thu May 16 2002 - 23:31:41 EDT
On Thu, 16 May 2002, Paul Rohr wrote:
> At 01:12 AM 5/17/02 +1000, Martin Sevior wrote:
> >I've been thinking about how to do these and I think that they could be
> >implemented with a simple meta-property "author" that is attached to all
> >piecetable changes during an editting session. ie Every piecetable frag
> >has an additional attribute - "author:........". Then layouts can be
> >built with different authors showing up as different colors.
>
> Martin,
>
> I'm really glad to see you thinking about this feature. As you say, it's
> must-have for corporate use.
>
> Three things to think about as you head down this path:
>
> 1. Before littering the document with frag-level author props (a cool idea,
> BTW), we should really add the "pruning" logic we've discussed in the past
> to not emit explicit properties that match the defaults.
>
> We already have this problem with cut & paste, where a side effect of the
> RTF impexp process generates a full set of redundant PROPS for each change.
> Or for a more comparable example, consider the current lang prop, which gets
> explicitly added to each block, rather than inheriting from the doc-level
> PROPS that Tomas suggested we add.
Maybe we should write a generic piecetable "cleanser" that removes
redundant properties without throwing change record and layout updates.
This could be run as an idle function if the piecetable is in
"dirty" state like our current background updaters.
It could proabablly be done in about 100 lines of code and would be quite
robust.
>
> 2. More importantly, how would you handle the "deletion" screw case? Say
> we have two successive modifications to a given draft:
>
> - RMS adds "GNU/" to all occurrences of "Linux", and
> - ESR goes back through and deletes them.
>
> At edit time, all of the deleted content exists inside the piece table, but
> by design none of it gets exported to the file format. Off the cuff, I
> don't see a trivial robust change to the file format which will handle this
> gracefully.
>
> 3. Finally, as a UI issue, I suspect that change tracking should be off by
> default. But we can cross that bridge when we come to it.
>
> bottom line
> -----------
> For revision marks to work well, we need to handle all three of the
> following style of changes: insert, change, and delete. The first is easy,
> the last is hard, and the second can be expressed as a combination of the
> other two.
I was thinking we could use our change records as used by the undo code
for this. They would needed to be XML-ized but we should do something like
this anyway to display undo "tooltips". ie Put mouse over the undo button
and see the last five operations.
The XML-ized change records would then be incorporated into the
document structure.
Dom and Jody (from gnumeric) are cooperating on a Journaling system
to allow automatic recovery after crashes. Maybe this could be extended to
cover these features too (revision marks and undo tooltips.).
Cheers
Martin
This archive was generated by hypermail 2.1.4 : Thu May 16 2002 - 23:35:24 EDT