- From: Mark Baker <distobj@acm.org>
- Date: Tue, 14 Apr 2009 10:51:31 -0400
- To: "SOAP/JMS (list)" <public-soap-jms@w3.org>
- Cc: Harald Alvestrand <harald@alvestrand.no>, Lisa Dusseault <lisa@osafoundation.org>, apps-review@ietf.org
On Mon, Apr 13, 2009 at 5:31 PM, Eric Johnson <eric@tibco.com> wrote: > As I pointed out in the email to Harald (are you on that mailing list?), > the jms URI, as spec'd, could be global in scope. For example, the > jndiURL parameter could point to a remote, globally accessible JNDI host. But AIUI, even that doesn't provide sufficient context to permit a third party to exchange information with the service, right? Anyhow, even if I'm mistaken about that, the important point is that this property isn't intrinsic to the scheme. > As a few simple counterpoints, the "file", "opaquelocktoken", "cid", and > "mid" URI schemes has a similarly local interpretation, but a global use. I don't see those as analogous. file URIs (even those without host parts) aren't interpreted locally, they're just resolved locally. Their interpretation is global. For example, "file:///etc/passwd" globally identifies the local /etc/passwd file, but of course, dereferences to a different file depending upon where it was resolved. For jms URI, only when a producer and consumer share the same context is an interpretation consistent. It's somewhat akin to defining a file-like scheme that used "foo:///asdfasdfas" to identify the local /etc/group file, where the knowledge of that mapping wasn't part of the scheme definition, or otherwise obtainable by any potential consumer of that URI. Mark.
Received on Tuesday, 14 April 2009 14:52:17 UTC