[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: funny parser

• To: 'Robin Berjon' <robin.berjon@e...>, "'Steven J. DeRose'" <sderose@a...>
• Subject: RE: funny parser
• From: "Bullard, Claude L (Len)" <len.bullard@i...>
• Date: Mon, 10 Oct 2005 09:33:23 -0500
• Cc: "'xml-dev@l...'" <xml-dev@l...>

Essentially the same "mess" as code patches.  Same
administrative overhead, same risks, same problems for
multiple instances of the code (say customers).

Won't this resurrect the 'version' permathread?

len

From: Robin Berjon [mailto:robin.berjon@e...]

Yes, that or an XPath should work quite well. It's routinely done in a
variety of situations. You may wish to look at XUpdate for instance
(assuming you want to reuse an existing piece of technology).

> Can you be certain that all change requests will be received, and in the
> order they were sent? If not, the problem gets much messier; but
> probably you can ensure that somehow.

It doesn't have to get terribly messy. With each update you send an
update number. You also provide a way for clients to request updates by
update number (which means you cache the n last ones, which would be a
cheap thing to do on disk). When a client gets an update that's more
than +1 above the last one it got, it requests the one(s) it's missed
before processing the one it has (you can also enforce that it
redownload the whole thing if it's missed more than a given number).

This assumes a bidirectional network, which appears to be what you have.
In a unidirectional network, you would caroussel the whole document
continiously, but you might schedule updates with a higher priority in
your broadcast.

• Follow-Ups:
  • Re: funny parser
    • From: Robin Berjon <robin.berjon@e...>

• Prev by Date: Re: how to skip parsing of a subtree?
• Next by Date: Re: funny parser
• Previous by thread: funny parser
• Next by thread: Re: funny parser
• Index(es):
  • Date
  • Thread