If it's using the OSD serialization methods in libomv, then there are several serializations available, including XML, JSON, and a binary format. I've used all three in projects and I've found the XML to be the most robust and mature. Depending on the version of libomv included with OpenSimulator, there may be bugs in formats other than XML.<div>
<br></div><div>Would any of the formats reduce the need for on-the-fly conversion between database and viewer? If the messages sent to the viewer are XML then I don't see JSON as a candidate, especially since we've used XML as a storage method in the past.</div>
<div><br><br><div class="gmail_quote">On Mon, Jul 5, 2010 at 4:23 PM, Teravus Ovares <span dir="ltr"><<a href="mailto:teravus@gmail.com">teravus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Not a whole lot of feedback here yet, maybe people are on a long<br>
weekend type camping vacation..<br>
<br>
I'm partial to OSD/json, myself.    I'd also like to, at some point,<br>
get a version number in there along with a definition of the format<br>
for people who want to write integration tools..    however, that last<br>
bit may be more of a 1.0 thing.<br>
<br>
I think a lot of tools are going to go the way of JavaScript in the<br>
future for various reasons...   one being that..   it's generally<br>
implemented in all web enabled devices.   Computers, 'tablets', 'smart<br>
phones'...   Another reason is it's more compact, while still being<br>
fairly human readable.     One last reason that I can think of at this<br>
moment is there are no external dependencies that 'get lost and turn<br>
into a 404', like with XML Schemas.   I've done several XML based<br>
integrations using REST and noted that in 55% of the cases, the<br>
defining schema is a 404 which makes validation and automatic creation<br>
of XML Serialization classes impossible.  Worse, in 15% of the cases,<br>
extensions are defined in the schema and then used in the XML..  Only,<br>
you won't ever know what tags and parameters the extensions provide<br>
because the schema is 'missing'.<br>
<br>
Regards<br>
<font color="#888888"><br>
Teravus<br>
</font><div><div></div><div class="h5"><br>
On Sun, Jul 4, 2010 at 8:28 PM, Justin Clark-Casey <<a href="mailto:jjustincc@gmail.com">jjustincc@gmail.com</a>> wrote:<br>
> Hi folks,<br>
><br>
> As part of the media-on-a-prim implementation, I'm serializing the<br>
> parameters for a media texture to the database.  This seems better than<br>
> creating new database fields or even a whole new table for these parameters,<br>
> both because there are lots of them (url, scaling, controls, whitelist,<br>
> etc.) and because different future virtual environments may want to store<br>
> different things.<br>
><br>
> I'm going to serialize them as an OSDArray or MediaEntrys using the<br>
> libopenmetaverse library.  However, the question then becomes whether to use<br>
> the JSON representation or the XML representation.<br>
><br>
> I tend to prefer XML for storage representations.  I believe that it's<br>
> somewhat more human readable and that there is better tool support for<br>
> manipulating it.  However, I know other people would prefer storage in JSON<br>
> and I accept that serialization/deserialization there may be slightly<br>
> faster.<br>
><br>
> The only other example of serialization that I know of in OpenSim currently<br>
> is that of SceneObjectGroups into inventory, which encompasses object<br>
> properties, object inventory properties and script state.  This is done in<br>
> XML and media entries would become part of that serialization.<br>
><br>
> If there's a majority preference for JSON I don't mind using that instead,<br>
> though I would want a justification for going this route rather than XML.<br>
>  If there's no real argument then I will go with XML.<br>
><br>
> Also, I believe that we should try and be consistent, so picking one or the<br>
> other now should make it more likely that the same approach would be used<br>
> for the next serialization case.<br>
><br>
> Regards,<br>
><br>
> --<br>
> Justin Clark-Casey (justincc)<br>
> <a href="http://justincc.org" target="_blank">http://justincc.org</a><br>
> <a href="http://twitter.com/justincc" target="_blank">http://twitter.com/justincc</a><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>
_______________________________________________<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></div>