- From: Mark Nottingham <mnot@akamai.com>
- Date: Mon, 22 Jan 2001 12:47:35 -0800
- To: "Nilo Mitra (EUS)" <EUSNILM@am1.ericsson.se>
- Cc: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>, "'w3c-xml-protocol-wg@w3.org'" <w3c-xml-protocol-wg@w3.org>
I put together an expanded case for caching a while back, don't know if it was considered. The current one is sufficient as far as caching is concerned, but it may be good to come up with separate use cases for implied requirements here - i.e., the ability for a Module to index into the body XML to assign cacheability, etc. Cheers * Caching Some applications may wish to make caching possible for latency, bandwidth use or other gains in efficiency. To enable this, it should be possible to assign cacheability in a variety of circumstances. For example, "read" caching might be used to store messages at intermediaries for reuse in the response phase of the request/response message exchange pattern. Such caching might be on the scope of an entire message, an XP module, or scoped to individual XP module elements. Similarly, "write" caching may be useful in situations when a request message in a request/response message exchange patterns (as well as similar messages in other message exchange patterns) does not need to be immediately forwarded or responded to. Such cachability might be scoped by different methods, as outlined above. Cacheability scoped by different elements might be associated by an attribute to the target element, through use of XML Query or XPath to describe the target elements in a header, or implied by the document schema, for example. Cacheability mechanisms applied to messages, bodies or elements might include time-to-live (delta time), expiry (absolute time), entity validation, temporal validation, subscription to invalidation services, and object update/purge. Finally, some applications may be capable of describing the dependencies and relationships between message elements. For example, a response element may be applicable to a wide range of requests; it would be beneficial to describe this element's relationship with request elements, so that it may satisfy a wide range of requests in an economical fashion. Similarly, the presence of a particular element may be a trigger for a cacheability mechanism to be applied to another element, such as validation or invalidation. On Mon, Jan 22, 2001 at 02:13:12PM -0600, Nilo Mitra (EUS) wrote: > Dear All: > I've gone through the xml-dist-app and w3c-xml-protocol mail lists and compiled the following use cases which have been submitted but > do not appear to have generated any discussion thus far. > > DS?? : Active XML element > source: http://lists.w3.org/Archives/Public/xml-dist-app/2000Nov/0209.html > see also: http://lists.w3.org/Archives/Public/xml-dist-app/2000Nov/0208.html > > DS?? : smart card re-valuation > source: http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0101.html > > DS??: communication libraries and application data > source: http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0207.html > > DS??: multiple, asynchronous response patterns > source: http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0208.html > > DS??: SAX-style XP handlers > source: http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0204.html > > DS??: thin clients and binary/application data > source: http://lists.w3.org/Archives/Public/xml-dist-app/2000Dec/0206.html > > DS?? : Internet Priniting Protocol scenarios for XP > source: http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0070.html > > DS?? ?? ?? ?? (4 of them, couldn't readily figure out if they had been subsumed elsewhere): Use cases for DRs 805, 807, 809, 810: > source: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Jan/0031.html > > Please let me know if I have missed any. > Thanks > > Nilo Mitra > Ericsson -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA)
Received on Monday, 22 January 2001 15:48:09 UTC