[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] Using Namespaces, IDs etc.
- From: slewis <slewis@xxxxxxxxxxxxx>
- Date: Sun, 03 Sep 2006 16:20:37 -0700
- Delivered-to: email@example.com
- User-agent: Thunderbird 18.104.22.168 (X11/20060719)
Erkki Lindpere wrote:
Why would it be good to include the username in the ID? One thing I
can think of is that the same bulletin board objects might look
different to different users, if they have different privileges.
Yes. I've been thinking that the ID could optionally include the
username as the URI spec
(http://www.gbiv.com/protocols/uri/rfc/rfc3986.html) includes an
optional 'authority' that is intended to represent the user@host:port
combination for the URI...and service URIs and IDs are generally
similar. But I have also been thinking that it would be up to the
service/namespace provider implementation to define what the appropriate
URI syntax would be for its namespace...so it may be that some providers
include/require the username in the ID, and others don't. For a
bulletin board API it seems to me the use of username needs to be
optional, as they don't all require/use them, but many do.
So far I've used actual WWW URL's, and some applications actually need
to get the actual WWW URL's somehow (for example the example.bbreader,
which gets them using id.toURI().toURL()), which is kind of bad, I
It doesn't seem so bad to me...why do you see this id.toURI().toURL() as
One thing I can think of to replace this method of getting the URL's
is to make the ID implementations adapt to URL, since ID's are
IAdaptable anyway and this would require no API change. Another way is
to implement an interface with a getURL() method and use instanceof
to know if an object has a WWW URL. I think I'd prefer adapting.
Yes we could easily introduce an adapter to do toURL(), but that would
actually be more code (to get the adapter) than the id.toURI().toURL()
idiom. Let me know why you would prefer an adapter that has getURL() to
I would also be inclined to make the ID include the username (if not in
anonymous mode). I assume that the ID could have URI-nature like:
or something like that. Having flexibility in the definition of the
targetID is the reason for the ECF namespace extension point (so
basically you can define your own URI for the given service).
ecf-dev mailing list