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

[Ed Merks <ed.merks@xxxxxxxxx>]

Scott,

I think we're both in the unenviable position of appearing as if we are 
arguing in favor of injecting EMF or ECF into the platform.  Hopefully 
folks will see beyond that so as not to lose sight of the technical 
unpinnings.  If we were to start Eclipse from scratch based on all the 
things we've learned, we'd likely do quite a few things a little 
differently...

Questions and comments below.


Scott Lewis wrote:
> Hi Jeff,
>
> Jeff McAffer wrote:
> > Scott Lewis wrote:
> > > RE: having one URI class used everywhere...I agree it would be 
> > > attractive, but extension is difficult given URI class is final (to 
> > > guarantee standards compliance among other reasons)...as in many 
> > > cases means writing wrappers (anyway) to have new constructors, 
> > > override other methods, etc.
> > I'm not sure what extension is needed.  can you elaborate or give an 
> > example?
>
> Sure.  One example needed extension is in URI construction.  Many IDs 
> have specific syntax requirements beyond the URI syntax spec...as a 
> concrete example:  xmppids.  So it's desirable/necessary to be able to 
> run custom String parsing code on construction.
I can see the point, but it seems a minor one and now I'm wondering 
about the context around this.    Consider how often a URI appears 
serialized in a document.  All I have is a string and I need to create a 
URI.  How will I know the right way to construct an ID given that there 
are many choices?  I can imagine that the choice might be based on the 
scheme, but that's easily addressed by registering a scheme-based 
validator with a single final implementation.   I also have a feeling 
that validation beyond "well-formed URI" could perhaps be left to the 
"interpreter" of the URI.    After all, a syntactically well formed "ID" 
could still be wrong for semantic reasons.
> > > ID:  Extensible using OSGi/Equinox mechanisms...e.g. extension 
> > > registry, adapters
> > > URI:  Impl has much functionality (already...yay),  Standards compliant
> > I tihnk there are some extension registry things in the EMF URI 
> > world.  Not sure what all they do.  Perhaps Ed can elaborate.
> > > Cons:
> > >
> > > ID:  Another abstraction so has some impl cost
> > > URI: Won't satisfy all use cases, so clients will still be 
> > > creating/need to create own ID types (at least for some things like 
> > > ECF connections)
> > API breakage aside, would it make sense to rephrase ECF API in terms 
> > of URIs?
>
> I don't think so.   Even with the 'loosest' URI structure...e.g.
>
> <scheme>:<scheme specific part>
>
> there are cases where unique identifiers (for some protocols) would 
> have to be forced into being a URI.  
Some concrete examples would help me a lot...  Note that there is a high 
level dichotomy between hierarchical URIs (<scheme>: followed by /) and 
opaque URIs (<scheme>: followed by anything other than /); you probably 
know that already..
> And for many other cases the URI class is overkill.  
True, but if we analyze the memory footprint of the wrapped things and 
their wrappers and compare that to a overkill uniform representation, is 
it really bad?  (I'm asking, I don't know.)
> For example...xmppids don't have any path (there's a resource 
> identifier, but it's not got any internal structure), and so all of 
> the path, query, etc stuff that is part of URI is cruft.
>
> > One thing that I did not get about the EMF stuff was the URIConverter 
> > class.  Here is some relevant JavaDoc
> > http://download.eclipse.org/modeling/emf/emf/javadoc/2.4.1/org/eclipse/emf/common/util/URI.html 
> >
> > http://download.eclipse.org/modeling/emf/emf/javadoc/2.4.1/org/eclipse/emf/ecore/resource/URIConverter.html 
> >
> >
> > the EMF approach has people creating URIConverter to do whatever they 
> > want with the various URIs.  So URIs are the ids (doh) and the 
> > converters make them "real".
>
> Yeah, I think (for good reason), most of the usage of URIs is for 
> resource IDs...i.e. things that generally have a path/name/ext etc.
Yes, hierarchical structure is quite important for most use cases, but 
it's 100% up to the URI converter to associate state with any given URI...
> One thought that I've had is that a new interface could be created 
> IResourceID:
>
> public interface IResourceID extends ID {
>
> org.eclipse.emf.common.util.URI getURI();
> }
I'm still curious how, if I have an arbitrary ID, I'd know what kind of 
adapter to create to do something meaningful for it.  I get the sense 
that an all encompassing representation that captures all cases will be 
the thing to which most folks will want to adapt...
> Then IResourceID could be used in appropriate places within p2 (and/or 
> e4) along with URIConverter, etc.  This would, I think, be both an 
> easy and useful way to go...as it would still be using emf.URI for 
> implementation, but gain the extensibility benefits of using the 
> namespace extension point.  The main cost to the programmer would be 
> calling (e.g.)
For the record, I doubt it's reasonable to move the existing EMF class 
somewhere else.  It's probably reasonable to copy it...
> resourceID.getURI().getPath() rather than resourceURI.getPath()  
> ...i.e. one level of redirection.
>
> Just a thought.  Even if URI is used directly in p2 we will certainly 
> do this ourselves if emf URI is added somewhere in Equinox.
Would you imagine that all IDs could be adapted to be represented as a 
URI?  Given such a URI, should it be possible to construct the 
"corresponding ID"?  Or is it the case that a given URI represent might 
represent different IDs is different domains and that they just happen 
to map onto the same URI representation?  (I think I'm asking the same 
ID -> String -> ID round trip question.)
> Scott
>
>
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev