[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] URLs, URIs, and IDs (oh my)
- From: Scott Lewis <slewis@xxxxxxxxx>
- Date: Mon, 29 Sep 2008 21:10:41 -0700
- Delivered-to: firstname.lastname@example.org
- Organization: Code9
- User-agent: Thunderbird 22.214.171.124 (Windows/20080708)
Some more thoughts about this.
Jeff McAffer wrote:
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);
This involves no changes to any existing interfaces...just namespace
extensions that know how to operate on Strings, emf URI, etc to return
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.