[Building Sakai] Alias namespacing
Stephen Marquard
stephen.marquard at uct.ac.za
Fri Sep 25 02:57:55 PDT 2009
Hi all,
In the beginning, the AliasService aliases (SAKAI_ALIAS) were all Email Archive aliases, e.g. a target of:
/mailarchive/channel/011d9ae1-44d2-4db1-aeef-f4c7b63edf77/main
Now we have aliases used for site aliases in the URL (settable in the UI in 2.7), e.g.
/site/6ab54a47-c987-433d-898f-7a6574f96170
and page aliases:
/site/fdf89eba-baa6-407c-ba96-3a3f959e6d29/page/ded30870-0fe3-417a-9987-2622a45fd02f
and RSS feeds:
/announcement/announcement/0d88f487-bc7e-4d60-99ed-1e0311137eb3
and iCal feeds:
/calendar/calendar/9913af17-37aa-40cb-0085-88a8096c0eb3/main
The RSS and iCal alias ids have ".rss" and ".ics" after them which is a sort of namespace-lite approach (as it would be possible to create say an email archive alias with those extensions).
I think we need a proper namespacing system for aliases. Either:
1. We add a separate type / namespace field and adjust the service methods appropriately, or
2. We adopt a convention for the ALIAS_ID field with a separator otherwise forbidden inside an alias, e.g. to create a new alias type for SMS, something like:
/sms/shortname
(where all aliases are forbidden from including /, i.e. Entity.SEPARATOR, in their alias ids, except as a namespacing identifer like this).
Any votes either way?
Regards
Stephen
Stephen Marquard, Learning Technologies Co-ordinator
Centre for Educational Technology, University of Cape Town
http://www.cet.uct.ac.za
Email/IM/XMPP: stephen.marquard at uct.ac.za
Phone: +27-21-650-5037 Cell: +27-83-500-5290
More information about the sakai-dev
mailing list