[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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/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.
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
- References:
- [p2-dev] URLs, URIs, and IDs (oh my)
- Re: [p2-dev] URLs, URIs, and IDs (oh my)
- Re: [p2-dev] URLs, URIs, and IDs (oh my)
- Re: [p2-dev] URLs, URIs, and IDs (oh my)
- Re: [p2-dev] URLs, URIs, and IDs (oh my)
- Re: [p2-dev] URLs, URIs, and IDs (oh my)
- Re: [p2-dev] URLs, URIs, and IDs (oh my)
- Re: [p2-dev] URLs, URIs, and IDs (oh my)
- Re: [p2-dev] URLs, URIs, and IDs (oh my)