[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Proposed new XML format

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-10-03 22:33:22 CEST

Jim Blandy <jimb@savonarola.red-bean.com> writes:
> them. I think Karl and Ben would say that the hierarchical format ---
> or, more precisely, knowing that the the hierarchical format is
> sufficient --- has really helped them in designing their modules.

It absolutely has.

> Those are all pretty fuzzy arguments. "Well, now we all know it can
> be done --- glad to hear you've persuaded yourself. So, what's the
> best textual format for deltas?"

:-)

> I'm not wedded to any particular syntax, but I do think a hierarchical
> form is a good thing.
>
> - It provides a restricted form for tree deltas that is easier to
> reason about than the less restricted forms. I do think that we
> will eventually care about this.

Although (as Jim points out) it feels like a weak argument to say "We
might care about this someday", I have to agree -- my instinct is also
that it might be important. In general, I think a restriction that
maps so suspiciously well onto the problem is one that shouldn't be
thrown away lightly, until we _know_ that everyone can get along
without it.

This is independent of the concern about getting Milestone 1 done, by
the way.

> - While none of our consumers require hierarchy at the moment, they don't
> mind it, either.
>
> - While none of our producers require hierarchy at the moment, they
> don't mind it, either.

What he said. :-)

> So I don't think hierarchy really limits our ability to plug arbitrary
> consumers and producers together. The case to watch out for is a
> consumer that can't easily produce hierarchical changes --- is mod_dav
> such a case?

Apparently, mod_dav is also working hierarchically (not that this was
a design goal of Greg Stein's, it just happens to work out that way).
Received on Sat Oct 21 14:36:10 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.