- From: \ <assini@kamus.it>
- Date: Thu, 08 Oct 1998 09:51:15 +0100
- To: "'DOM list'" <www-dom@w3.org>
keshlam@us.ibm.com wrote: > Smart XML cache does sound like the way to go. Of course the API it would > present to the application would in turn be a DOM, plus whatever methods > are required to control the cache behavior. > > As far as I can tell, the back-end API -- the protocol between the cache > and a document server -- is currently left as an exercise for the reader. > One can argue about whether or not it should simply be a networked version > of the DOM interfaces. > Exactly, it would be DOM on both the client and the server side (the cache mechanism will access XML on the server through DOM and will present the result as DOM at the client). The internal protocol between the cache's server and client side naturally could not be DOM itself. I see it as a kind of feedback mechanism with: - a connection through which the server side cache continuously sends to the client the XML elements that it forecasts the client is going to ask for - a feedback call that the client side will use to correct the server side guessing by explicitly requiring the elements that it can not find in the local cache The main problem is to figure out the heuristic that the server is going to use to forecast client behaviour. Should we use some kind of self adaptive genetic algorithm ? It might be the case, we start from the principle that the bottleneck is in the network, not in the processing time (otherwise a cache would not be needed in the first place) so some computing intensive but powerful algorithm could be the correct choice. BTW this cache could be used not only to access far distant XML files but also XML Databases and dynamically built (and possibly infinite length) XML. It sounds as an interesting programming exercise, anyone interested in working on it ? Regards. -- Pasqualino "Titto" Assini The Data Archive - University of Essex, UK
Received on Thursday, 8 October 1998 04:51:14 UTC