[Opensim-dev] HG Versions and Changes

[Diva Canto]

Yes, I understand the need for versioning, I just want to make sure that 
we're all on the same page :)

There are some important things that affect how compatibility is 
handled, both in time and diversity, and things can still go in 
different directions. Something that seems as simple as adding a version 
number actually is not that simple... I know that most people out there 
don't care about technical details, and they shouldn't care. "Most 
people", however, should not be using developers code, where this work 
is being done. In the next official release, OpenSim 0.7.1, HG will be 
clearly marked as incompatible with OpenSim 0.7.0.2, and that's what 
most people need to know.

For everyone who cares about technical details, let me explain a few 
more things directly related to the issue of versioning.

First of all, HG is a set of services, not just one -- gatekeeper and 
user agents (core HG, that includes the simulation service), plus an 
open-ended list of resource services such as inventory, assets, etc. The 
fact that some services are in incompatible versions doesn't necessarily 
mean that the whole thing will fail; there may be partial failures. So 
there needs to be versioning associated with the individual services, 
it's not just one sequence of numbers. The bump that happened a few 
weeks ago affected the simulation service, which is part of the core HG. 
Unfortunately, that happened while I was busy with other things, so 
there was no notification about it here on -dev.

Second, currently, HG 1.5 supports protocol negotiation in some parts, 
but not in others [yet], namely negotiation is supported in asset and 
inventory access. What this means is that these services don't even need 
to be talking the same wire protocol in order for grids to interoperate. 
Specifically, right now we're supporting two different network handlers: 
Robust and Simian -- they package the data in completely different ways, 
and yet all of that is transparent to the HG protocol, and things [will] 
work.

WRT versioning, protocol negotiation has a non trivial consequence; if 
some backwards incompatible change happens, say, in the Robust inventory 
handlers, it doesn't affect the Simian handlers at all, and vice-versa. 
So there are version numbers associated with the network handlers of 
each service, additionally to the type of the network handlers, and 
additionally to the version number associated with abstract HG protocol 
itself, which is 1.5 at the moment.

There are advantages and disadvantages in negotiating network handlers 
in the overall HG protocol, and I'm not sure which way this will end up 
going. If we keep protocol negotiation, and extend it to all services, 
then we clearly need different sets of version numbers; if we can all 
agree in one single data representation for the entire set of services, 
forever, then we can merge the abstract HG protocol with a [single] 
specification regarding the data that gets transmitted for each service, 
and have one single sequence of version numbers (but still associated 
with the individual services, probably).

The way things will end up is not something that I can decide by myself, 
as the mere existence of the issue conveys the existence of many people 
with different perspectives, and the System-to-System nature of the HG.



On 12/12/2010 1:13 PM, kidd piko wrote:
> On Sun, Dec 12, 2010 at 6:13 PM, Diva Canto<diva at metaverseink.com>  wrote:
>> We have been using "interface version numbers" to refer to communications
>> between simulators and their central services *within* grids. We introduced
>> these numbers mainly because of OSGrid, where the central services are run
>> by one group of people and the simulators are run by others, and therefore
>> the software upgrades are not coordinated.
>
> Diva,
>
> Thank you for your informative posts regarding HG versioning,
> interface version numbers, and OSGrid's proxy issues. Anyone who was
> unclear on those topics should be well informed now.
>
> To further clarify some of the earlier statements that Ai made, any
> reference to interface numbers in relation to the HG 1.5 protocol has
> been purely out of neccessity.
>
> IMHO, just as "interface version numbers" were introduced to help
> coordinate communications between simulators and their central
> services, the decentralized peer-2-peer network of the thousands of
> active HyperGrid nodes also need adequate version numbers in order to
> coordinate communications between each other.
>
> Even though the HG 1.5 protocol has not changed, the facts on the
> ground are that grids/standalones using Interface 6 cannot communicate
> with grids/standalones using Interface 7. No matter how many times
> someone is told that the HG 1.5 protocol has not changed, it does not
> change the fact that they cannot travel to the same destinations that
> they could before they upgraded to Interface 7.
>
> As you are aware, we manage a network of 300+ HyperGates. Every week
> we provide hundreds of HyperGrid addresses to HyperGrid travellers via
> those HyperGates and via our web site http://TheHyperGates.com . When
> HyperGate owners began updating to revisions that contained the newer
> Interface 7, it quickly became clear that all Interface 7
> grids/standalones could only travel between each other and could no
> longer travel to destinations that had not updated yet.
>
> When this incompatibility became appearant, we were sure that even
> though the HG 1.5 protocol had not changed, a new revision or
> maintenance number was going to be announced in order to coordinate
> communications between compatible HyperGrid destinations. Something
> like an "HG 1.5.1" announcement would have made the situation
> instantly clear to many HyperGrid travellers and region owners alike.
>
> When this new HG revision/maintenance number announcement was never
> made, we were forced with either providing people incompatible HG 1.5
> destinations or splitting our HG 1.5 HyperGate Network into 2 seperate
> networks and coming up with our own naming to differentiate between
> the two. Since the only difference between the two networks was the
> Interface number that they each used, we decided to label the two
> networks according to their Interface numbers: i.e. HG 1.5 i6 and HG
> 1.5 i7.
>
> We strongly support any decision to begin version numbering the HG
> protocol in an effort to better indicate compatibility.
>
> We are all fully aware the OpenSim is still in alpha and that HG still
> needs a lot of work, but the first time HG traveller doesn't care
> about version numbers and can't be bothered to hunt down the
> undocumented ins and outs of HyperGridding. To them, it either works
> or it is broken. And first impressions can mean a lot.
>
> Anything that can help region/grid owners build a more reliable mesh
> of HyperGrid destinations for their first time HG travellers, can only
> help the overall advancement of the HyperGrid.
>
>
> kidd
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>