[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [p2-dev] URLs, URIs, and IDs (oh my)
|
Hi Jeff,
Jeff McAffer wrote:
awesome note. thanks Scott. I had some chocolate instead of a
beverage. Here is my response.
Can you give a code sample that would, for example, take a given ID
(say an arg) and do some path manipulation on it and then open a File
with the new ID? I just want to see how this would work in practice.
Sure. In the file transfer API we have an ID sub-interface called
IFileID, which are based upon URLs [1]. The usage is currently
something like this:
IFileID newID = FileIDFactory.getDefault().createFileID("provider.name",
new URL("file:/c:/temp/foo.bar"));
This is then (e.g.) passed into the file transfer API
sendRetrieveRequest(newID,...). Inside of the filetransfer
implementation, we have some code that calls
String filename = newID.getFilename();
I'm of course aware that getFilename() isn't all of what is
needed/desired for URI-based file manipulation, etc...but this is all we
needed for the filetransfer/browse API to this point so that's the 'file
manipulation' method that's there currently. But I'm expecting to
create other interfaces (e.g. IUrlID or IUriID or better names :), that
have more/other methods exposed by emf URI, java.net.URI, maybe just use
the IPath/IFile in Equinox core, etc. based upon p2 and/or e4's
requirements.
It's also possible, BTW, to use adapters rather than to have
sub-interfaces (like IFileID). That is, it's also possible to do:
IFileID fileID = (IFileID) existingID.getAdapter(IFileID.class);
// use the fileID assuming it's non-null
So the use of sub-interface (compile-time) or adapter (runtime) are both
available.
Scott
[1]
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/filetransfer/identity/IFileID.html
Jeff
Scott Lewis wrote:
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
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev