[
Lists Home |
Date Index |
Thread Index
]
Steven J. DeRose wrote:
> At 15:52 +0200 2005-10-10, Dirk Huenniger wrote:
>> But usually reality does not change quickly and only a 1KB/minute
>> actually changes in the XML file. So what about the server sending parts
>> of the XML file. Only the ones that just changed. This way the Clients
>> don't have to poll anymore, and we get rid of the bandwidth problem. Of
>> course the Clients still have to load the file at the beginning but this
>> is only done once.
>
> How about putting an ID on every changeable node, and then sending
> something like:
>
> <replace target='someID'>
> ...new XML for that node...
> </replace>
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.
--
Robin Berjon
Senior Research Scientist
Expway, http://expway.com/
|
