Hi Folks,
I wanted to throw out some thoughts WRT using URLs, URIs, and IDs
based upon
a) the brief discussion this morning on the p2 weekly call;
b) some related things being discussed on the e4 mailing list around
common connection management [1]
P2 Context: The immediate issue with our current usage of URLs is
defined by the p2 plan item: "Convert from using URL to URI where
possible", aka bug #237776 [2]
E4 Context: See [1]
Some Observations
a) For both P2 and E4 it's it's necessary to move away from only using
URLs....primarily, I would say, because the URL (as specified in RFC
2396 [3]) is insufficiently general to support out-of-process
identification of 'entities' (resources like files of course, but also
services...for p2 repositories, for e4 connections, etc). There are
other reasons not to use URLs as well (e.g. [2]), of course.
b) The natural 1st alternative to consider is java.net.URI (first
introduced in 1.4.2 I believe, also defined by RFC 2396). There is
also the EMF URI class [4] , which is almost certainly a better
implementation...i.e. requiring fewer resources, and providing more
functionality. Further, there are other implementations of the
URI...either implementations of just RFC 2396 and/or having other
functionality. IMHO, there will likely be more in the future e.g. [8].
c) ECF created it's ID interface [5] in order to define an
out-of-process unique identifier (for resource ids, but also for user
ids, service ids, process ids, etc) that we could use within our own
transport-independent connection framework [6]. When this identity
API [7] was created, it was created to support the many ways of
addressing and connecting to external processes that would be
necessary for ECF-based communication. At the time of creation we
wanted to allow clients to run ECF-based code on the CDC 1.0 OSGi
profile, which does not support URI...so there is (so far) no direct
reference to URI class currently in the ecf.identity package(s).
I would like to assert that it would be a good idea to consider using
ECF's ID/Namespace API (contained fully within
org.eclipse.ecf.core.identity bundle), for both p2 and e4. I say this
not (just) because ECF created ID/Namespace interfaces, but rather
because I think there would be weaknesses in any implementation based
upon a non-extensible URI class. BTW, I say 'non-extensible' because
the java.net.URI and emf.URI classes are (quite correctly) marked
final...for security as well as other reasons.
Some reasons:
a) The java.net.URI class is pretty clearly written specifically to
implement the RFC, meaning that where the RFC is vague, the
implementation is vague. This means, for example, that there would
likely have to be a lot of code duplicated around manipulating paths
in file URIs, creating URIs, etc.
b) java.net.URI is pretty weak in a number of respects where emf URI
is strong. e.g. resource usage, functionality, etc. OTOH obviously
java.net.URI is 'out there' as it's in the JRE for 1.4+.
c) It would be useful for p2 repository implementers and connection
implementers [e4] to be able to define their own identifier syntax.
That is, since URI cannot be extended, everyone is basically required
to use one implementation or do a lot of converting back and forth
(e.g. consider clients built that use p2, and emf, and ecf, and DSDP,
etc). Further, it's a pain (particularly with java.net.URI) to
introduce new schemes...because it means adding *greater* constraints
upon the construction of URIs (being more specific than the
RFC)...e.g. like requiring some set of properties for your new scheme,
or defining a whole new syntax....you can't create subclasses and new
constructors. Of course you can create factories that return URI
instances (of some URI impl, and do their own String parsing).
d) There are others, but this note is getting too long already.
e) The ECF ID/Namespace API can easily *use* either/both/many URI
implementations. There is an extension point called
org.eclipse.ecf.namespace that allows plugins to define new
Namespaces, and these Namespaces basically have control over creating
IDs for the given Namespace). So, for example, it would be trivial to
add a URINamespace, that constructed ID's that wrapped URI instances
(either emf URI or java.net.URI) and used them for ID instances. And
alternative impls could be swapped out later. Further, either ID
subinterfaces (e.g. IFileID...see [8]) OR adapters could be defined
that exposed the public methods of either/both of java.net.URI and emf
URIs. This would allow clients to either case or adapt the ID
implementations in order to use the URI-specific methods (e.g.
emf.URI.hasRelativePath()). It's my expectation for some time that
such interfaces will be added to ECF identity or dependent plugins so
adding them is likely in the cards whether IDs/Namespaces are used for
other things or not.
This note is long enough so I'll stop there. Even if this doesn't
make sense for whatever reason we (ECF) will introduce support for
java.net.URI-based providers as well as emf.URI-based providers so
that URIs of either type can be used to construct IDs, and the
underlying URI can be accessed via the associated ID.
Thanks for reading. Now I suggest having a beverage of your choice
before responding...but then, please respond :).
Scott
Links
[1] http://wiki.eclipse.org/E4/Connection_Frameworks,
http://wiki.eclipse.org/September_11%2C_2008_E4/Connectivity_Meeting
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=237776
[3] http://www.ietf.org/rfc/rfc2396.txt
[4]
http://download.eclipse.org/modeling/emf/emf/javadoc/2.5.0/org/eclipse/emf/common/util/URI.html
[5]
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/core/identity/ID.html
[6] http://wiki.eclipse.org/ECF_Connection_Creation_and_Management
[7] http://wiki.eclipse.org/ECF_API_Docs#ECF_Core
[8] http://labs.apache.org/webarch/uri/,
http://hc.apache.org/httpclient-3.x/apidocs/org/apache/commons/httpclient/URI.html,
http://ws.apache.org/axis/java/apiDocs/org/apache/axis/types/URI.html
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev