> Ugh, I think we need to talk about this. It sounds like you're
> unwilling to keep track of a "stack" within your editor
> implementation
No, I'm fine with keeping a stack in the editor implementation if it's
necessary. It's just that so much of the meshing between the editor
interface and a hierarchical output format is based on what you did
last. Consider the following sequence of calls:
1. replace_root() --> root_baton
2. replace_dir("foo", root_baton) --> foo_baton
3. replace_file("bar", foo_baton) --> bar_baton
4. change_prop("name", "value", foo_baton)
5. replace_file("baz", foo_baton) --> baz_baton
[...]
Let's see how much we can confidently write at each step.
Step 1: We can write the XML header and <delta-pkg>. We can't write
<tree-delta> because we're not sure any changes are coming.
Step 2: Okay, now we can write out the <tree-delta> from the last
step, since we know there are changes. We can also write out
<replace name="foo"><dir>.
Step 3: Again, we write out <tree-delta> from the last step, and we
write out <replace name="bar"><file>.
Step 4: We write <prop-delta><set name="name">value</set>, but we
can't write out </prop-delta> yet because there might be more property
changes coming for this file.
Step 5: First, we have to write out a </prop-delta> to finish up step
4 since we can now see there are no more properties to be set.
Second, we have to write out a <text-delta-ref id="something"/> to
finish up step 3 because, although bar_baton hasn't been closed, we
are no longer working on it, and since we haven't seen a text delta
yet we assume one is coming at the end. Then we write out
</file></replace>. Only now are we ready to write out <replace
name="baz"><file>.
As I said, this can be done. At the begining of each call, you have
to "unwind the stack" until you get to the type of baton you're
operating on. (It's not really a stack as such because you never have
to unwind past the topmost directory baton; all you really need is a
state register which says what type of element you're inside, and a
pointer to the file baton being worked on, if any.)
If this were the only problem, I'd say no problem, I'll just do the
work. But on top of that, what I'm really hearing from the other
developers on this project is:
* We want producers to be able to traverse in arbitrary order,
not just in the order mandated by hierarchal XML deltas.
* We want to be able to plug arbitrary producers into
arbitrary consumers.
* We want hierarchical XML deltas.
One of these things has got to bend. Since XML deltas aren't even
being used by the version 1.0 network protocol, I think it's best to
bend the third one.
Received on Sat Oct 21 14:36:10 2006