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 <mela...@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@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
.
--
Justin Clark-Casey (justincc)
OSVW Consulting
http://justincc.org
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
