[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] URLs, URIs, and IDs (oh my) - summary

John,

Comments below.

John Arthorne wrote:

> IMHO the EMF URI impl is technically superior to java.net.URI and should be used for all impls

I'm curious what this opinion is based on. Apart from a couple of convenience methods, the only differences I see with the EMF implementation are deviation from RFC 2396 to handle
It would be interesting to consider footprint.  I see on the order of 17 fields, with a great many strings.  I'm not sure if there's much in the way of string sharing going on, but only measurements will tell... Generally they are very similar in terms of accessor methods (not surprisingly because they implement the RFC).  The path in EMF is represented in a more fine-grained way...  That might save space but then again, it might not.
Windows devices and archive URIs ("jar:file:/a!/" is not hierarchical but EMF's URI says it is).
Yes.  This is important because only hierarchical URIs support resolve and deresolve and it's often important to interpret relative paths within an archive.   I suspect this would cause issues when using URIs.
The first deviation means that it won't properly handle file: URIs on non-Windows platforms that have a segment containing the : character.
I'm not sure how that follows.
Both deviations mean it behaves quite differently from java.net.URI, so when you inevitably need to convert between the two you're likely to get into trouble.
I'm not sure that follows either.  Generally if you create it with a string, you get the same string back when you ask for that string representation.  I suspect the manipulations of archive URIs will require special case handing with java.net.URI...
 The EMF class does optimize for space over speed compared to java.net.URI, but in our situation of one URI per repository the space is not an issue.
Paths in the the IResource APIs were important compared to strings; I wonder if URIs didn't cause an issue?
As for convenience methods, these are easily added as static methods on a utility class, which beats reimplementing and maintaining the 3000+ lines of a URI implementation. There are also several conveniences lost in the EMF class such as resolve(String), toFile(), toURL(), and other class library conveniences like new java.io.File(URI), and java.io.File.toURI().  
Of course you can add those...  You won't be using EMF's URI anyway.  You'd be creating your own.  If there are no advantages from being able to optimize or tailor your own, you'd definitely be best to reuse something that exists.

We have a somewhat bad habit in Eclipse of reinventing the wheel when we perceive the Java class library isn't good enough.
Can you say icu4j? :-P
This creates a barrier for Java developers coming to Eclipse who have to learn the quirks of our different implementations. This also creates friction when Eclipse APIs need to interact with non-Eclipse APIs that use either the class library or their own custom implementations, introducing not only the overhead of conversion but subtle bugs due to differences in implementation.
In this case, the String-> URI -> String -> anything else should generally avoid that.
There is also of course the bloat and maintenance overhead of carrying your own implementation. Overall I agree that java.net.URI lacks some conveniences, and can be maddeningly strict at times in its interpretation of the RFC, but I can live with it. I reimplemented the workspace using java.net.URI and found it to be a perfectly capable implementation once you learn how to use it.
It's not clear given what you've said, why you don't just use String?  When you need to manipulate it in detail, you create a structured representation and when you're done, you turn it back a string...

John




Scott Lewis <slewis@xxxxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

10/01/2008 07:05 PM

Please respond to
slewis@xxxxxxxxx; Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>

To
P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc

Subject
Re: [p2-dev] URLs, URIs, and IDs (oh my) - summary







I thought I would take a note to give my 'lessons learned' summary from
the discussion to this point:

1) For implementation, URI is the obvious/natural choice.
   IMHO the EMF URI impl is technically superior to java.net.URI and
should be used for all impls

2) It's an open question as to whether *also* using IDs + extensible
Namespaces are worth the costs of abstraction.   IMHO the needs vary
significantly by project:
   p2:  URI probably could be used in every place needed...as it's
almost always resources (meta-data files) that are being referred
to....at least AFAIK
   e4 connection framework:  I'm of the opinion that using URI *only*
for all connections would be doable-but-clumsy...and that it would make
sense to use ID's
   with easy access to URIs for resources (e.g. IResourceID)
   ECF: we will use IDs (interface) and EMF and/or java.net.URI
(Equinox/OSGi-available impl) so clients can use what makes sense for
them (resource-based or not)

3) Don't let your API get put in a competitive position with an API done
by Ed 'Ice Man' Merks :).  Actually, I hope it's clear to all that
ID/Namespace is *not* a competitive alternative to use of URI (whether
java or emf)...as clearly for resources some impl of URI/RFC 2396 is the
way to go.  But what I suppose I should have said more clearly up front
is that ID/Namespace in *addition* to URI is a possible way to get both
some greater generality, and therefore supporting some use cases that we
(ECF) have found important e.g. non-resource-based
connections/identifiers like user ids, service ids, channel ids, group
ids, etc.

Scott

_______________________________________________
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