[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Using Namespaces, IDs etc.

Hi Erkki,

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 admit.

It doesn't seem so bad to me...why do you see this id.toURI().toURL() as problematic?

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 the toURI().toURL().



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