[Opensim-dev] Optimize pushing assets to other grids

Justin Clark-Casey jjustincc at googlemail.com
Tue Apr 1 00:03:12 UTC 2014


I originally put in the MajorInterfaceVersion back in 2008 but I now think that's a very bad way to handle updates in a 
distributed system with no central control.

Instead, just like the web, the protocol should be designed with extensbility in mind so that the system can evolve 
without massive disruption [1], allowing old and new components to co-exist.

I think that one more planned bump of MajorInterfaceVersion would be acceptable to introduce extensibility but continual 
bumps are going to do damage to the system and people's confidence in the system.  Not only does it affect the Hypergrid 
idea, but also in a large grid it makes it very difficult, if not impossible, to experiment with newer updates if they 
are not protocol compatible.

I'll also note that the version number has not been bumped since October 2010.  Unsurprisingly, nobody has wanted to 
inflict (or be blamed) for that pain so everybody has been at pains not to introduce incompatible updates (or only 
incompatible in minor ways).  But really this compatibility should be achieved with a planned mechanism rather than the 
ad hoc measures that have always been used, and where one day luck runs out.

[1] https://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_2

On 31/03/14 17:51, Melanie wrote:
> There is no implicit versioning in the actual request protocol. That
> would have been impossible to maintain in the long run. Instead,
> there is a "protocol version". We can bump it when there are
> incompatible changes on any protocol and it invalidates all of them.
> So a sim version 7 will refuse to connect to a server version 6 and
> vice versa. This gives us both control and simplicity.
>
> Melanie
>
> On 31/03/2014 18:45, Jim Williams wrote:
>> Seems reasonable to me...A design approach I would have taken.
>>
>> One question.  Is there some sort of versioning built into the protocol?
>>   One verb yes, but the dictionary numbers the definitions.....
>>
>>
>> On Mon, Mar 31, 2014 at 12:35 PM, Melanie <melanie at t-data.com> wrote:
>>
>>> This isn't designed as RPC, it's designed as REST. One URL/VERB
>>> combination for each function.
>>> We wanted to get away from the RPC concept. Let's not take backwards
>>> steps here.
>>>
>>> Melanie
>>>
>>> On 31/03/2014 15:15, Oren Hurvitz wrote:
>>>> This isn't overloading: it's an RPC endpoint that accepts many methods.
>>> You
>>>> wouldn't create a separate endpoint for each method, would you?
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579104.html
>>>> Sent from the opensim-dev mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> .
>


-- 
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc



More information about the Opensim-dev mailing list