[Opensim-dev] Bump GridComms Version Notice
Frisby, Adam
adam at deepthink.com.au
Sat Jul 25 23:45:57 UTC 2009
I think ultimately; we shouldn't be using LLSD in anywhere that isn't explicitly dealing with CAPS and it's required.
Frankly it's not an ideal serialisation format for anything but LL compatibility.
Adam
From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Dahlia Trimble
Sent: Saturday, 25 July 2009 4:18 PM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Bump GridComms Version Notice
I've noticed one issue already with the "core" split after 0.7, references that were originally resolved to OpenMetaverse.dll now are in the new Core dll. This broke binary level compatibility with third party dlls, and source projects now need to be distributed assuming either configuration.
On Sat, Jul 25, 2009 at 4:06 PM, Jim Radford <jradford at npl.com<mailto:jradford at npl.com>> wrote:
OSD (StructuredData) != Types, Full release notes:
http://jira.openmetaverse.org/secure/ReleaseNote.jspa?version=10071&styleName=Html&projectId=10000&Create=Create
Although I notice there is nothing in those release notes that indicates
the breaking changes since 0.6.x, We (libomv) need to be better about
flagging changes as such. They are generally flagged as breaking in the
commit message, the problem is we don't always create jira issues for such
changes (bad behavior on our part). We'll get this process fixed so
breaking changes in 0.8 will be more obvious. Its probably worthwhile to do
a svn log (or browse through the -commits mailing list) which might help
indicate other possible issues in updating to 0.7.0.
Additionally the specifics of the change Teravus talks about were done due
to a change in the OGP draft specs which the commit message indicates If
memory serves me correctly.
And lastly, one of the major projects for 0.8 will be to split the "core"
functionality (messages, packets, etc) into its own assembly separate from
client related items. This will for opensim of course mean a leaner
assembly without a bunch of the stuff you don't currently need. This change
will not be much in the way of API/Namespace changes. The desire is to
continue to support the many use cases for the library but in a more
organized fashion that makes better sense in those use cases.
Teravus: thanks for pointing these things out so we can improve the
process.
Regards,
Jim
On Sat, 25 Jul 2009 18:41:22 -0400, "Frisby, Adam" <adam at deepthink.com.au<mailto:adam at deepthink.com.au>>
wrote:
> D'oh.
>
> Wasn't moving to OMVTypes supposed to avoid breaks like this?
>
> Adam
>
>> -----Original Message-----
>> From: opensim-dev-bounces at lists.berlios.de<mailto:opensim-dev-bounces at lists.berlios.de> [mailto:opensim-dev-<mailto:opensim-dev->
>> bounces at lists.berlios.de<mailto:bounces at lists.berlios.de>] On Behalf Of Teravus Ovares
>> Sent: Saturday, 25 July 2009 2:05 PM
>> To: opensim-dev
>> Subject: [Opensim-dev] Bump GridComms Version Notice
>>
>> Hey everyone
>>
>> After fighting with things for a bit, I'm going to recommend bumping
>> the version of the gridcomms.
>>
>> It turns out that the json serialization of the UUID type was changed
>> in libOMV revision r2588 to a plain string.
>> This leaves older regions expecting a 'uuid::' prefix (as was the
>> previous format) unable to decode UUIDs and return a UUID.Zero.
>>
>> This will break Hypergrid and some types of region to region comms
>> between OpenSim revisions 10081 and 10082. Regions in versions 10082
>> cannot talk properly to regions 10081 and below. If you try, some
>> regions will show, some won't, you'll have border crossing issues
>> sometimes and you'll get weird console messages. For grids who want
>> a consistent experience, you will need to upgrade regions together so
>> organize the effort appropriately.
>>
>> Unfortunately, there isn't really anything that we can do besides this
>> except roll back the LibOMV 0.7.0 commit and stay on an older version
>> of libOMV. There isn't any way to programmatically change, without
>> forking OpenMetaverse.StructureData, what should go over the wire
>> serialization. Additionally, on the receiving side, there's no way
>> to know what was a UUID and what was a string with UUID text in it's
>> contents so converting it there is also out of the question.
>>
>> Additionally, any services that make use of the json serialization are
>> affected (json stats come to mind).
>>
>> Be aware of these changes
>>
>> Regards
>>
>> Teravus
-- Jim
!DSPAM:370,4a6b8ffa312361761917752!
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de<mailto: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/20090725/ed1f4a6b/attachment-0001.html>
More information about the Opensim-dev
mailing list