[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] Using Namespaces, IDs etc.
- From: "Erkki Lindpere" <villane@xxxxxxxxx>
- Date: Thu, 24 Aug 2006 13:12:51 +0300
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kcB6LsLP/ojls090r4TwB1ILeZgRuI1tZR6BB1W3pPLLL7bVVGVxIAXGT6xL4QMXpfWY/zLAfJMCOURVgftIsjhSWJHLNLLUykNTEi4syrcJaSRAwj8G9/jgxMGcRGJ2N/y25WM2LAO2dm0vr8iioYkKnOozcUWM04UvZdZZumk=
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.
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
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.
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).