[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [p2-dev] URLs, URIs, and IDs (oh my)
|
Hi Ed, Jeff,
I don't want to make this a battle between Ed (URI) and me (ID) :).
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.
Some pros as I see them
ID: Extensible using OSGi/Equinox mechanisms...e.g. extension registry,
adapters
URI: Impl has much functionality (already...yay), Standards compliant
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)
I assume others can/will identify other pros and cons.
Scott
Jeff McAffer wrote:
For the record, I introduced IPath into this discussion as an
illustration to tease out some detail. There are many places where we
simultaneously manipulate String, IPath, File and URL (often in the
same method). Most of our current bugs or "quirks" come from the
conversions between these forms.
Ed, for your example of the URI with a query, it likely would not make
sense to use IPath. Pragmatically, there are similar disconnects
using URI. In many usecases we know/expect that the location is a
filesystem location and eventually do new File() so the query stuff is
dropped anyway. Just saying that there are cases where the
information dropping is not an issue.
Given the need to interact with some legacy code, are there converters
for URI to get IPaths and URLs (and the other way)?
It would be quite illuminating to see the Path test suite rewritten in
terms of URI to see if all the device and canonicalization is equivalent.
Naively I see the current discussion evolving as ID vs EMF URI. Not
trying to pit one against the other but rather compare and see the
pros and cons. The idea of having one (URI) that is the superset of
the function is attractive assuming the cost is not high. There was a
point raised earlier about extensibility and URI (it was hard?) but I
did not understand the jist. Can someone restate?
Thanks
Jeff
Ed Merks wrote:
Scott,
Would IPath really be a valid way to manipulate a general URI? I.e.,
suppose the URI was
http://www.eclipse.org/projects/project_summary.php?projectid=modeling.emf;
what would be the IPath and if one asked for the getFileExtension
would it return "php"? The conversions, as Jeff is pointing out, do
seem very problematic to me. It would seen that conversion to the
most general possible form and always manipulating via that form is
the only "properly general" way. If that's a valid conclusion, it
starts to argue in the direction that this most general
representation perhaps ought to be the one uniformly used everywhere...
Scott Lewis wrote:
Hi Jeff,
Some more thoughts about this.
Jeff McAffer wrote:
<stuff deleted>
Many of the usecases don't really involve ECF at all (parish the
thought :-). In the broader Equinox/Eclipse context what we need
is generic, handy and effcinet ways of manipulating path-like
structures. Sometimes they are for files, sometimes URL-like
things, ... The real challenge in this space is in encoding and
all the UNC/platform whackiness and the conversion between the
different forms (e.g., new URL(<unc string>).getPath() does not
give you what yoy might hope for).
How do you see IDs fitting in? Would the adapter facility allow
people to convert between the different forms?
Yes, it would. So I would envision something like this
Let's suppose some new ID namespaces are created...based upon/using
URL, File, EMF URI, java.net URI.
So then client would call:
ID theID = <created externally>
IPath p = (IPath) theID.getAdapter(IPath.class);
foo(p);
This involves no changes to any existing interfaces...just namespace
extensions that know how to operate on Strings, emf URI, etc to
return an IPath.
We didn't/haven't been using path manipulation as our driving use
case up to now...rather we've got adapters like IFileID, IChatID,
etc implemented by our namespace extensions. But especially given
the existence of good implementations for URI (e.g. emf), IPath
(i.e. core.Path), etc. the technical effort to provide such
implementations doesn't seem large to me for such use cases.
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
- 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)