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

[Matthew Jones]

Okay, I see what you're saying now. I guess what you're talking about then
is.

Pros over UUID
- Shorten the amount of space needed in the database from 36 to 22
characters for these, possible slight also improvement on the cache
- Possible performance improvement on the lookups because of the shortened
character space
- Still have a useless to the user "secret code" for most sites/tools/etc
on the URL line, but about half as long as before

Cons over UUID
- Could *possibly* cause regressions if someone is doing something like
splitting this UUID or processing it somehow/somewhere?
- Harder to visually make sense of the data. (Generally now I can pretty
easily remember the first 4-8 hex digits and that's usually all you need
when doing quick visual comparisons, harder with a 62 verses, 16 character
space)
- Each grouping of the UID's does have meaning, and probably some
efficiency if processed as hex, but we never do that so this is irrelevant.
- Has a non zero chance of generating an inappropriate word phrasing
randomly that the user would see in the URL (like some CAPTCHA's do
sometimes)

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?


On Wed, Jan 8, 2014 at 11:35 PM, Charles Severance <csev at umich.edu> wrote:

> Matt -
>
> You keep making this too complex.  Short URLs require a database table.
> We cannot afford to add lookups all the places where we work with GUIDs.
>
> I am simply saying we change this line of code:
>
> kernel-impl/src/main/java/org/sakaiproject/id/impl/UuidV4IdComponent.java
>
>     public String createUuid()
>     {
>         return UUID.randomUUID().toString();
>     }
>
> Not to use the toString() method but instead take UUID.randomUUID() and
> generate a Base-62 encoding of  the uuid instead of a Base-16 encoding with
> some dashes.
>
> Nothing more.   Instantly makes all of our URLs shorter.  Low risk - no
> performance impact.
>
> /Chuck
>
> See also:
> http://stackoverflow.com/questions/772802/storing-uuid-as-base64-string
>
> On Jan 8, 2014, at 4:50 PM, Matthew Jones <matthew at longsight.com> wrote:
>
> Sorry, I must have only skimmed the summary.
>
> In that case, I don't see much point. Shortened URL service already does
> this better. If we're going, short, you want to go as short as possible,
> get rid of portal/site all that, maybe even a shorter domain name. Whether
> it's a 10 character encoded or 36 character encoded URL doesn't seem like
> it makes any difference in an expanded form. And it ends up making
> (slightly) harder for those in tiered support to figure out the
> relationship between the URL and the site, you'd have to go through this
> type of algorithm or site look-up table somewhere to get that information
> out of the database? Then you'd probably want these encoded ids to work
> with /direct/ to work with /access/, to work with the admin tools, not just
> portal. Seems dangerous if it's not super easy to expand these to the user
> again anywhere anyway.
>
> Look at something like on Amazon, this URL is far from pretty, it's got a
> ton of crazy data in it, but a small bit is the short part.
>
> http://www.amazon.com/Sakai-Free-as-Freedom-Alpha-ebook/dp/B005227LYO/ref=sr_1_1?ie=UTF8&qid=1389217620&sr=8-1&keywords=charles+severance
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140109/1f43849d/attachment.html