Hi Mark,
Thanks again for your additional feedback.
Mark Baker wrote:
On Fri, Mar 20, 2009 at 11:05 PM, Harald Alvestrand
<harald at alvestrand.no> wrote:
Thanks - those words help.
The important point is that use of the URI depends on a shared context, and
that context cannot be identified from the URI. Indeed, there may be valid
cases where the same URI is resolvable in two different contexts, with two
different results.
That leaves me sad, because it is exactly opposite to what the "U" in "URI"
sometimes stood for,
Me too 8-(
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.
It is certainly hard for us to know whether this current situation is an
accident of the historical adoption of JMS, or whether it generally
isn't useful on the internet global scope.
Certainly, one of the reasons we're putting this proposal forward is to
facilitate the adoption of SOAP over JMS. This seems relevant to me,
because we currently have an enormous amount of code and effort going
into handling SOAP messages over HTTP in a reliable and secure fashion.
With JMS, you get these characteristics (almost) without having to
define additional layers of specification to handle reliability and
encryption at the payload layer.
Given an available standard for SOAP over JMS, could that drive a more
global use for JMS itself? Hard to say.
As a few simple counterpoints, the "file", "opaquelocktoken", "cid", and
"mid" URI schemes has a similarly local interpretation, but a global use.