Hi guys!

No time to dwell in detail but I wonder two things:

1. I have always envisioned a Delta to be first *read* into the image
and then *after* that - either applied or reverted or whatever. So the
"reading" part would ONLY instantiate the totally self contained object
graph of the delta. And thus - why would reading chunks in reverse be
interesting?

2. Again, since IMHO the reading part should ONLY build the graph - why
would the chunk format be a bad choice? I always envisioned the simplest
and most flexible chunk format to be first some code to get a reader
(making it easy to hook in alternate readers) and then simply "feed"
that reader by sending messages to it that builds the Delta. In essence
it probably would boil down to one message per change (roughly) object.
Now... that doesn't expose any internal structure (ivars of DSChange
classes etc) so... as long as the readers grok the original set of
messages - how would that be problematic when it comes to schema
evolution?

Lastly - I like the current balance in the DSChange hierarchy between
"abstractness" and "concreteness" - I really don't want to make it more
abstract or generic, as a step towards the Pier model sounds like in my
ears. I like code that I can touch, feel and understand. I don't like
code which makes me feel I don't ever get to see "the meat" of the
action. :)

Which btw is why I sometimes feel slightly dizzy when the Visitor
pattern gets overused. Again in the DSChange hierarchy I wrote a visitor
mechanism but intentionally kept it a bit more intention revealing - and
yes, thus I did not FULLY exploit the genericness of the Visitor pattern
- but that was actually on purpose. Well, Matthew knows what I mean I
guess. :)

regards, Gšran