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

[Matthew Jones]

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

The shortened form they offer as an alternative (if you click to generate
it) is just http://amzn.com/B005227LYO.

Sakai offers the same option though shortened URL. Maybe it's not exposed
enough?



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

> Matt,
>
> To be clear -
>
> I was *only* planning on changing the *encoding* so that URLs are shorter
> and don't have minus signs.   My proposal is simply to switch from hex
> encoding with dashes to base-62 encoding with no dashes.  I was not trying
> to generate the numbers in a new way.   Just make URLs shorter.
> Especially URLs with both site and tool ids on them...
>
> I used the YouTube example just as a shorter example, I assumed they did
> something to keep them unique other than GUID logic.  I also was
> uninterested in Oracle or MySQL performance per se - I was not suggesting
> that we either (a) convert old (long GUIDs) , (b) switch to integers, or
> (c) shorten the field lengths for GUIds in the code.
>
> So this is really simple and very localized in the code.   Generate the
> guid and then encode using base-62 [a-zA-Z0-9].  Performance won't be
> significant - once we generate these - they are treated as a string anyways.
>
> The question is as much  a UI question - will people like or dislike a
> switch from
>
> https://sakai.edu/portal/site/8923c6aa-794f-43f0-8ea2-dc6f96556d6b
>
> to
>
> https://sakai.edu/portal/site/Xh1snj0jIWc
>
> Neither is particularly pretty...   The second is shorter.
>
> /Chuck
>
>
> On Jan 8, 2014, at 12:19 PM, Matthew Jones <matthew at longsight.com> wrote:
>
> This is the "standard" format. [1] You can base64 or some other encode
> this to save a few bytes, trading space for CPU and performance complexity.
> I'm not sure what's better.
>
> The youtube format has a smaller number set, but their algorithm that
> generates the number the backing value guarantees uniqueness only based on
> that internal value, and it's not randomly picked.
>
> I believe that the initial reason for using GUID (instead of just auto
> increment which would have been more efficient) was so you could take this
> data in one Sakai system, and move it over to another Sakai system. If you
> used something that was based on an algorithm which was active on another
> system on fixed numbers, you'd very certainly have collisions. With GUID,
> the possibility of this is the same as the possibility on the same system.
>
> The way MySQL and Oracle index these text values, there really isn't any
> performance problem with retrieval, so you're really only looking at the
> savings in a few bytes of storage per GUID. I think, unless you're changing
> this data type all the way down to a numeric value like an INT/NUMBER,
> there won't be too much of a noticeable gain?
>
> [1] http://en.wikipedia.org/wiki/Globally_unique_identifier
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140108/1e4de569/attachment.html