[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [p2-dev] URLs, URIs, and IDs (oh my)
|
I'm thinking of something that would be equivalent to
foo(IPath path) {
path = path.removeLastSegments(2);
path = path.append("foo");
path = path.addFileExtension(".txt");
File file = path.toFile();
OutputStream out = new FileOutputStream(file);
}
Many of the usecases don't really involve ECF at all (parish the thought
:-). In the broader Equinox/Eclipse context what we need is generic,
handy and effcinet ways of manipulating path-like structures. Sometimes
they are for files, sometimes URL-like things, ... The real challenge
in this space is in encoding and all the UNC/platform whackiness and the
conversion between the different forms (e.g., new URL(<unc
string>).getPath() does not give you what yoy might hope for).
How do you see IDs fitting in? Would the adapter facility allow people
to convert between the different forms?
Jeff
Scott Lewis wrote:
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
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev