- From: Hugo Haas <hugo@w3.org>
- Date: Thu, 17 Oct 2002 16:07:50 +0200
- To: www-ws-arch@w3.org
Hi Doug. * Doug Bunting <db134722@iplanet.com> [2002-10-16 14:17-0700] > When reading comment 1, I immediately think of the MIME content-location header > and its use in exactly this situation. Some efficiency may be lost through > having to fall back to retrieving from the URI when not present in the message > rather than immediately knowing a GET (for example) is necessary. However, the > manifest information provided in the SOAP envelope or other payloads does not > need to change. This might have a different solution (such as your proposed > "API") when using DIME. That may be a solution to the problem, although, as you said, concrete (not necessarilly conforming) instances of of the Attachment Feature having different properties. It is worth some text in the abstract framework about this though, and I think that this is what comment 1 is about. Do you want to add some specific text to it? > I would probably extend the current motivations to mention "caching versus > single source" performance arguments. When the payload is available externally > to the message and retrievable using a GET (again, for example), it may be > cached. When everything is available in the received message, the application > has everything it needs immediately to begin processing. Improved latency > either way, depending upon the cache hit ratio? Agreed, although I think that this choice will come up when a designer will make a choice of a binding. Do you want to send a comment to the XML Protocol Working Group about this? > Separately, I believe Dave should have said "cid:someidentifierforSoundwav". > The URI identifies a part of the current message, not a distinct message or this > (current) entire message. Good catch! Regards, Hugo -- Hugo Haas - W3C mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
Received on Thursday, 17 October 2002 10:07:52 UTC