[Building Sakai] Idea: Change the GUID generator for Sakai

[Matthew Jones]

Didn't even consider that one Stephen, which is essentially the main realm
query. So if you eliminated 26 more characters there really isn't any gain.
It seems like removing the 4 dashes from the GUID seems like the only easy
savings you'd can get without writing some custom base~32 algorithm. (That
would encode only lower case, digits and -, excluding vowels). Basically
Crockfords scheme [1] where he already considered these points.

[1] http://www.crockford.com/wrmg/base32.html

On Thu, Jan 9, 2014 at 6:39 AM, Stephen Marquard <stephen.marquard at uct.ac.za
> wrote:

>  In mysql, these two are equivalent:
>
>
>
> SELECT * FROM SAKAI_REALM WHERE
> REALM_ID='/site/bf438025-925a-481f-80b3-aa628eacd93b';
>
>
>
> SELECT * FROM SAKAI_REALM WHERE
> REALM_ID='/site/bf438025-925a-481f-80b3-aa628eacd93B';
>
>
>
> i.e. the comparison is case-insensitive by default. So I’m not sure that
> any encoding scheme including both A-Z and a-z is a good idea.
>
>
>
> All round, this seems like a potentially very disruptive change for
> minimal gain.
>
>
>
> Regards
>
> Stephen
>
>
>
> ---
>
> Stephen Marquard, Learning Technologies Co-ordinator
>
> Centre for Educational Technology, University of Cape Town
> http://www.cet.uct.ac.za
> stephen.marquard at uct.ac.za
> Phone: +27-21-650-5037 Cell: +27-83-500-5290
>
>
>
> *From:* sakai-dev-bounces at collab.sakaiproject.org [mailto:
> sakai-dev-bounces at collab.sakaiproject.org] *On Behalf Of *Matthew Jones
> *Sent:* 09 January 2014 07:42 AM
> *To:* Charles Severance
> *Cc:* dev sakai
> *Subject:* Re: [Building Sakai] Idea: Change the GUID generator for Sakai
>
>
>
> Maybe disaster is a little extreme, but depending on who it happened to,
> it would be at least a significant event, and depending in which tool it
> was generated could be some database related effort to clean it and/or
> change it. So base 54 maybe, (Unless there are other safe characters to
> replace)
>
>
>
> Though the commons function already replaces + and / with - and _ so
> probably not many characters left. "Encodes binary data using a URL-safe
> variation of the base64 algorithm but does not chunk the output. The
> url-safe variation emits - and _ instead of + and / characters. *Note: no
> padding is added."*
>
>
>
> On Thu, Jan 9, 2014 at 12:35 AM, Matthew Jones <matthew at longsight.com>
> wrote:
>
> I don't know, thinking about it more, I think that last point would be a
> disaster if it happened. :) Would want to eliminate vowels from the
> encoding?
>     ------------------------------
> UNIVERSITY OF CAPE TOWN
>
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer
> published on our website at
> http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27
> 21 650 9111. This e-mail is intended only for the person(s) to whom it is
> addressed. If the e-mail has reached you in error, please notify the
> author. If you are not the intended recipient of the e-mail you may not
> use, disclose, copy, redirect or print the content. If this e-mail is not
> related to the business of UCT it is sent by the sender in the sender's
> individual capacity.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140109/ffeae796/attachment.html