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

["Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>]

Ah, you are right. I stand corrected.

>From the resource standpoint, and EFS in particular, the URI works
great. The extensibility comes by adding layers on top of the URI based
on the scheme, in our case by mapping scheme to IFileSystem which
manages the additional functionality. Clients obviously need to know
about the extensions to call them. But I think we're in control of that.

Anyway, just an example of where URIs in action. I'm not familiar enough
with ECF to know whether this applies there, though.

Doug.

> -----Original Message-----
> From: p2-dev-bounces@xxxxxxxxxxx 
> [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Scott Lewis
> Sent: Tuesday, September 30, 2008 2:48 PM
> To: P2 developer discussions
> Subject: Re: [p2-dev] URLs, URIs, and IDs (oh my)
> 
> Hi Doug,
> 
> Schaefer, Doug wrote:
> > Hmm, I thought the U meant Universal. Maybe not so?
> >   
> 
> Actually, my understanding is it means Uniform:  
> http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
> 
> RE:  URI...notwithstanding my obvious interests in 
> representing ECF's value in a broader community...I agree 
> that URI can be used quite successfully and naturally for 
> representing identity of 'resources' 
> (hence the 'R' ;-)...that's our (ECF's) intention.  But as 
> per my previous comments, it can be both too much (lots of 
> functionality that's inappropriate for some identifiers) and 
> too little (limited/difficult
> extensibility) for some use cases that are important...to us 
> at least (e.g. connections to xmpp servers, or irc servers, 
> or multicast groups, named asynchronous data channels, etc., 
> etc., etc). 
> 
> If supporting those use cases are not that important for a 
> connection framework (although I would argue they should be 
> supported in such a framework), or for p2 (which obviously 
> seems to me to be much more resource focussed in it's use of 
> URLs for identifying repos), then by all means it would make 
> sense to use emf URI alone.  In bringing this up I was simply 
> trying to identify (no pun intended) what I consider a 
> weakness of using URI for cross-process identity...and 
> offering an alternative at the level where generality and 
> extensibility seem pretty important to me:  Equinox, p2, e4 
> (i.e. Platform in whatever form).
> 
> Scott
> 
> 
> 
> 
> > Doug. 
> >
> > I don't have anything more useful to say other than I'm 
> watching this 
> > thread in consideration for how we'll deal with Resource 
> > identification for e4. URI seemed to be the best answer. But then 
> > we're being influenced by EMF guys too :).
> >
> >   
> >> -----Original Message-----
> >> From: p2-dev-bounces@xxxxxxxxxxx
> >> [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Scott Lewis
> >> Sent: Tuesday, September 30, 2008 12:40 PM
> >> To: P2 developer discussions
> >> Subject: Re: [p2-dev] URLs, URIs, and IDs (oh my)
> >>
> >> 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.
> >>
> >>
> >>     
> >>>> 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.  And for many other 
> cases the URI 
> >> class is overkill.  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/eclips
> >> e
> >>     
> >>> /emf/common/util/URI.html
> >>>
> >>>
> >>>       
> >> 
> http://download.eclipse.org/modeling/emf/emf/javadoc/2.4.1/org/eclips
> >> e
> >>     
> >>> /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.
> >>
> >> 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();
> >>
> >> }
> >>
> >> 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.)
> >>
> >> 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.
> >>
> >> 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
> >   
> 
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev
>