They are very much an issue; the Architecture Working Group on the Linden Labs grid is currently attempting to work out many of these sorts of details. Search the group in-world, it's free to join and fascinating whether as a spectator or participant.<br>
<br>Cheers<br>Hiro/daTwitch<br><br><div class="gmail_quote">On Fri, Jun 13, 2008 at 9:08 AM, James Hughes <<a href="mailto:jamesh@bluewallgroup.com">jamesh@bluewallgroup.com</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;">
<div><div></div><div class="Wj3C7c">Sean Dague wrote:<br>
> 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>
</div></div>> ------------------------------------------------------------------------<br>
<div class="Ih2E3d">><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>
</div>Something I have thought about concerning UUID's and grid<br>
interoperability is this; do things like textures, clothing, shapes need<br>
a common UUID to work properly? Also, some things may need to carry bits<br>
of information to identify the originating grid.<br>
<br>
Is it too early, yet, to start thinking about those things? Or, are they<br>
even an issue?<br>
<br>
<br>
Thanks,<br>
<br>
BlueWall <j><br>
<div><div></div><div class="Wj3C7c">_______________________________________________<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>===================================<br>The wind<br>scours the earth for prayers<br>The night obscures them