[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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