[Opensim-dev] standardizing on uuid string formats

Fri Jun 13 19:42:38 UTC 2008

I agree with everyone's comments about the importance of human 
readability; though it's scary to think that anybody would consider 16 
bytes of hex, however formatted, readable.

But why is the actual implementation so important? Why can we not wrap 
this kind of specific in a set of utility services that makes the actual 
underlying representation irrelevant, provided it can be resolved to a 
valid  16 byte UUID sequence? I don't see why the underlying 
implementation shouldn't be a 16-byte unsigned integer, and the formatting 
at the whim of the user. Isn't this a fundamental precept of object 
oriented programming?

Regardless, the right implementation will be one which defines the nature 
of this beast in one place, and one place only.

Best regards
Alan
-------------------
T.J. Watson Research Center, Hawthorne, NY
1-914-784-7286
alan_webb at us.ibm.com

Stefan Andersson <stefan at tribalmedia.se> 
Sent by: opensim-dev-bounces at lists.berlios.de
06/13/2008 12:15 PM
Please respond to
opensim-dev at lists.berlios.de

To
<opensim-dev at lists.berlios.de>
cc

Subject
Re: [Opensim-dev] standardizing on uuid string formats

+1 on 2

basically, agreeing with everything said about human readability over 
clock cycles

Best regards,
Stefan Andersson
Tribal Media AB

Join the 3d web revolution : http://tribalnet.se/

> Date: Fri, 13 Jun 2008 08:36:57 -0700
> From: cmickeyb at gmail.com
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] standardizing on uuid string formats
> 
> +1 on format 2
> format consistency at the database storage level will help
> tremendously in writing consistency checkers.
> 
> might also want to specify standard character set... we currently use
> UTF8 and latin1 (at least in the mysql tables).
> 
> --mic
> 
> 
> On Fri, Jun 13, 2008 at 6:00 AM, Sean Dague <sean at dague.net> wrote:
> > We have 3 serialization formats for a UUID
> > * XXXXXXYYYYYYZZZZZZ....
> > * XXXXXX-YYYYYY-ZZZZZZ....
> > * binary packed version (used in the mysql assets table exclusively)
> >
> > This is definitely confusing. One of the reasons that we got here is
> > that there never was really a defined standard, and things grew and
> > changed over time. One of the reasons that we are still here is that
> > until recently, doing database migrations between formats would have
> > been a lot of crazy logic. I'm hoping that the Migration support I 
just
> > put in (and switched both SQLite and MySQL over to) should fix part 2.
> >
> > So, back to part 1. I think we should declare a standard, and work
> > towards getting everything in that standard. My suggestion, and
> > preference here is form 2: XXXXXX-YYYYYY-ZZZZZZ... for the following
> > reasons.
> > * It's very user readable, and like the format that people have come 
to
> > expect in the client viewer. As people like looking at their data in
> > both xml and in the database, making it make more sense to them is
> > probably a good thing
> > * It's the native string format for LLUUID and GUID (system built in).
> > Using another format means lots of converting back and forth.
> > * It also occured to me this morning that the extra string in every
> > conversion might account for some of our extra overhead.
> >
> > All opinions on the table are valid. I firmly believe that anything
> > that gets our data more self consistant will help with maintainability
> > in the project. Please throw in your views, and I'll queue this up for
> > future work.
> >
> > -Sean
> >
> > --
> > __________________________________________________________________
> >
> > Sean Dague Mid-Hudson Valley
> > sean at dague dot net Linux Users Group
> > http://dague.net http://mhvlug.org
> >
> > There is no silver bullet. Plus, werewolves make better neighbors
> > than zombies, and they tend to keep the vampire population down.
> > __________________________________________________________________
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> >
> > iD8DBQFIUm+ESamXem9TdyYRAmlmAJwIPbjgfk1KEPJ0uYDsyogoc+JgoQCgpl/q
> > gGE0KcWqi/7TTpP7KHQcIoI=
> > =hUsu
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080613/82961f79/attachment-0001.html>