Re: [ogpx] The Urgent Need For Protocol Negotiation (Was: Beyond the monolithic client protocol endpoint)

[Carlo Wood <[e-mail]>]

On Mon, Dec 07, 2009 at 05:40:30PM -0600, Suzy Deffeyes wrote:
> 
>     * In the latter case (the service not knowning about it) the viewer
>      needs to fall back to the old style map on opensim and to a hardcoded
>      S3 url on Second Life (which DOES support this capability, but just
>      doesn't know about the "capability" url itself).
> 
>     * Once Linden Lab (or any other grid that will implement the same
>      way that map works) stops supporting the "old style map", there
>      is no way to tell the client explicit that THIS "feature" (the
>      new way of how map works) is now mandatory, other than the
>      existing method of requiring a minimal *viewer* version... which
>      of course only works for the few viewers that are supported this
>      way and which is a very crude way to state that one feature is
>      now mandatory (bound to fail once there are lots of features
>      like this to be negotiated).
> 
> 
> So in the map tile case you mention, if the viewer gets a cap to the new way of
> fetching tiles, it wouldn't try to do the old way.

Well, if it DOES get a cap, then clearly the service DOES know about the
feature, so there is little need for the old style map.

> In this particular case,
> it seems like getting a cap for http fetch of map tiles deprecates client use
> of the old mechanism.

Yup. The problem that I tried to demonstrate that needs protocol/feature
negotiation is for the case that the server does NOT return a cap.


Wouldn't it an ideal world if in the end we'll have One Big Virual World ;)
(rethorical question). But, one world or not (and certainly in the case
where we have many different worlds) in the end we will have many different
branches of servers. Server implementations written by different people,
with different goals and ideas.

At the client side the same thing will happen. Right now we ONLY have six
or so separately maintained viewers; that number will grow a lot in the
future up till the point where it is unpractical to maintain communication
between client and server coders.

If we all can convince ourselves that the standard that we will produce
here is THE BEST-- and does not need ANY extensions or extra features,
then surely we will decide that what we make here is the Best For Everyone,
and Nobody Needs More. However, we are not the (only) server developers
of the future, and I predict that there will be a growing number of
server developers in the future that WILL feel the need for some new,
till then unsupported feature.

What is going to happen is that there WILL be a growing set of "features"
on top of the VWRAP standard, and no controlled way to communicate all
those features to the viewer developers... To make a long story short,
it will become a mess. Soon you will only really be able to connect to
server type "opensim" if you use their viewer; and only connect to
Second Life if you use Linden Lab's viewer.

The viewer coders will get frustrated about that, because they want
to allow their users to connect whereever. So, they need to make their
viewer adjust to the protocol as function of the server type that they
connect to.

At first, it would be sufficient to add some kludge to detect the major
grids (as it works for "their own" viewer), but the growing number of
servers and features will make a nightmare of this. Server version
detection will be needed, and then the viewer coders will need to start
to keep track of which versions of each server-type support what
features. The methods used to determine if some feature is optional
and whether or not a viewer can or want to use it will also be
random (everyone implementing their own way). Some server developers
will only support a few viewers and keep a list of versions of those
viewers and then "negotiate" the features silently by assuming that
viewer MyOwnViewer version 4.35 is compatible and has features
A,E,J,M,N,X and Z, while FurryViewer version 1.11 is not compatible
but 1.12 is but only supports features A,E,X and Z. Now LittleViewer
can't connect at all (except for using the base VWRAP protocol)
except by spoofing it's version and saying it is really FurryViewer,
however LittleViewer's coder didn't really want to add feature X,
rather wanted just to support feature F...

Buttom line, this isn't about ONE application (a server) with a
compatible viewer (client) that is controlled and maintained by
the same people as the server. This is about a large network of
servers and clients maintained and developed dynamically by many
different groups and we DO NEED TO SUPPORT protocol evolution
in order to avoid a complete future mess.

If anyone doesn't believe that (or thinks that we can do this
with just caps and the other methods already proposed in OGP)
then I beg you to add this anyway: if no features are added
then we're talking about three or four small, standard messages
(two each direction) for each client-server connection, and
no harm done.

If anyone doesn't WANT this, because they don't want to see the
protocol evolve, because a *standard* means that everyone uses
the same, and therefore building in ways to add random features
would only invite people to make viewers incompatible; then please
reconsider. I strongly believe that not adding support will
not stop people. Besides, it isn't bad if the protocol changes
over time at all imho; look at it as evolution: support for the
best features will be added to all viewers and servers, other
features won't make it and die again. As long as it is crystal
clear who supports what, and the documentation of each and every
feature can easily be found back on the web, then I think we
only gained.

-- 
Carlo Wood <[e-mail]>