+1 SDague :D<br><br>The human overhead of dealling with this suite of formats for the same datatype has put me off working up patches almost since the day I discovered it to be the case.<br><br>I'm all for standardization. In fact, I could care less which format is chosen as long as one is chozen and we live with it.<br>
<br>Obviously, one is likely more efficient than the other, and there are obviously other considerations - but I say pick one and go, and I'll live with it.<br><br>Cheers<br><br>Hiro/daTwitch<br><br><br><div class="gmail_quote">
On Fri, Jun 13, 2008 at 8:00 AM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We have 3 serialization formats for a UUID<br>
* XXXXXXYYYYYYZZZZZZ....<br>
* XXXXXX-YYYYYY-ZZZZZZ....<br>
* binary packed version (used in the mysql assets table exclusively)<br>
<br>
This is definitely confusing. One of the reasons that we got here is<br>
that there never was really a defined standard, and things grew and<br>
changed over time. One of the reasons that we are still here is that<br>
until recently, doing database migrations between formats would have<br>
been a lot of crazy logic. I'm hoping that the Migration support I just<br>
put in (and switched both SQLite and MySQL over to) should fix part 2.<br>
<br>
So, back to part 1. I think we should declare a standard, and work<br>
towards getting everything in that standard. My suggestion, and<br>
preference here is form 2: XXXXXX-YYYYYY-ZZZZZZ... for the following<br>
reasons.<br>
* It's very user readable, and like the format that people have come to<br>
expect in the client viewer. As people like looking at their data in<br>
both xml and in the database, making it make more sense to them is<br>
probably a good thing<br>
* It's the native string format for LLUUID and GUID (system built in).<br>
Using another format means lots of converting back and forth.<br>
* It also occured to me this morning that the extra string in every<br>
conversion might account for some of our extra overhead.<br>
<br>
All opinions on the table are valid. I firmly believe that anything<br>
that gets our data more self consistant will help with maintainability<br>
in the project. Please throw in your views, and I'll queue this up for<br>
future work.<br>
<br>
-Sean<br>
<br>
--<br>
__________________________________________________________________<br>
<br>
Sean Dague Mid-Hudson Valley<br>
sean at dague dot net Linux Users Group<br>
<a href="http://dague.net" target="_blank">http://dague.net</a> <a href="http://mhvlug.org" target="_blank">http://mhvlug.org</a><br>
<br>
There is no silver bullet. Plus, werewolves make better neighbors<br>
than zombies, and they tend to keep the vampire population down.<br>
__________________________________________________________________<br>
<br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.6 (GNU/Linux)<br>
<br>
iD8DBQFIUm+ESamXem9TdyYRAmlmAJwIPbjgfk1KEPJ0uYDsyogoc+JgoQCgpl/q<br>
gGE0KcWqi/7TTpP7KHQcIoI=<br>
=hUsu<br>
-----END PGP SIGNATURE-----<br>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>===================================<br>The wind<br>scours the earth for prayers<br>The night obscures them