[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