[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