My 2cents:
The most important thing here is to make sure there is a mechanism in
place for alternative formats. Personally, I have no preference for any
format; the best format depends on the context of the application. Since
we are doing a framework, we must assume that these applications will
exist in a variety of contexts. Hence the absolute requirement that we
will be able to plug in whatever serialization procedure we want.
On 7/5/2010 6:08 PM, Dahlia Trimble wrote:
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.
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.
On Mon, Jul 5, 2010 at 4:23 PM, Teravus Ovares <[email protected]
<mailto:[email protected]>> wrote:
Not a whole lot of feedback here yet, maybe people are on a long
weekend type camping vacation..
I'm partial to OSD/json, myself. I'd also like to, at some point,
get a version number in there along with a definition of the format
for people who want to write integration tools.. however, that last
bit may be more of a 1.0 thing.
I think a lot of tools are going to go the way of JavaScript in the
future for various reasons... one being that.. it's generally
implemented in all web enabled devices. Computers, 'tablets', 'smart
phones'... Another reason is it's more compact, while still being
fairly human readable. One last reason that I can think of at this
moment is there are no external dependencies that 'get lost and turn
into a 404', like with XML Schemas. I've done several XML based
integrations using REST and noted that in 55% of the cases, the
defining schema is a 404 which makes validation and automatic creation
of XML Serialization classes impossible. Worse, in 15% of the cases,
extensions are defined in the schema and then used in the XML.. Only,
you won't ever know what tags and parameters the extensions provide
because the schema is 'missing'.
Regards
Teravus
On Sun, Jul 4, 2010 at 8:28 PM, Justin Clark-Casey
<[email protected] <mailto:[email protected]>> wrote:
> Hi folks,
>
> As part of the media-on-a-prim implementation, I'm serializing the
> parameters for a media texture to the database. This seems
better than
> creating new database fields or even a whole new table for these
parameters,
> both because there are lots of them (url, scaling, controls,
whitelist,
> etc.) and because different future virtual environments may want
to store
> different things.
>
> I'm going to serialize them as an OSDArray or MediaEntrys using the
> libopenmetaverse library. However, the question then becomes
whether to use
> the JSON representation or the XML representation.
>
> I tend to prefer XML for storage representations. I believe
that it's
> somewhat more human readable and that there is better tool
support for
> manipulating it. However, I know other people would prefer
storage in JSON
> and I accept that serialization/deserialization there may be
slightly
> faster.
>
> The only other example of serialization that I know of in
OpenSim currently
> is that of SceneObjectGroups into inventory, which encompasses
object
> properties, object inventory properties and script state. This
is done in
> XML and media entries would become part of that serialization.
>
> If there's a majority preference for JSON I don't mind using
that instead,
> though I would want a justification for going this route rather
than XML.
> If there's no real argument then I will go with XML.
>
> Also, I believe that we should try and be consistent, so picking
one or the
> other now should make it more likely that the same approach
would be used
> for the next serialization case.
>
> Regards,
>
> --
> Justin Clark-Casey (justincc)
> http://justincc.org
> http://twitter.com/justincc
> _______________________________________________
> Opensim-dev mailing list
> [email protected] <mailto:[email protected]>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
_______________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
