Thanks for the answers.
> I think the editor can intuit which to do like so. If you see
> close_dir() or something that opens a new file_baton (add_file(),
> replace_file(), add_dir(), or replace_dir()) before seeing
> close_file(), then you should generate a text-delta-ref and store it
> in the file_baton under the assumption that a text-delta for that
> file_baton will come along later.
But the file's contents didn't necessarily change; maybe only the
properties changed. So you don't know whether a text-delta is coming
later or not.
Some other issues:
* The producer of edit_fns calls is allowed to change the
file's contents after closing the enclosing directory or
opening a new file. Is there a prop-delta-ref?
* Although the producer of edit_fns calls is restricted to a
single traversal of the tree, it doesn't have to be
depth-first. But XML delta output is hierarchical; how can
you stop and go back to a directory later if the producer
doesn't give you calls in depth-first order?
Is there any reason why the producer contract allows the producer to
open a new file or directory without closing the old one? I'll note
that if the producer were restricted to a depth-first traversal,
edit_fns could be drastically simplified; no more need to pass
directory, file, and window handler batons back to the producer;
everything would be relative to the last file opened or to the top of
the directory stack.
If there is a reason for this producer flexibility, then the XML delta
format probably needs to be made non-hierarchical, or we won't be able
to produce XML deltas streamily.
> The important question is, are you going to implement this, or am I?
Well, I'd like to have something to do. :) (This project has too many
qualified developers.) Sorry I forgot about your stating your intent
to work on this.
Received on Sat Oct 21 14:36:09 2006