[sldev] Snowglobe on OpenSim grids

[Suzy Deffeyes]

I originally added the map tile cap to my Snowglobe 1.3 wishlist  
because currently when http texture fetches are enabled, OpenSim users  
get completely wrong map tiles. That's just rude for them.  I wanted  
to fix it for existing OpenSim grids, so they could implement serving  
the correct map tiles via http.

I wasn't thinking of it as vwrap related, although it does illustrate  
the interesting dance from udp to http, and some of the issues with  
that.

Can we make a simple fix for OpenSim now that will still work with the  
existing Linden grid, irrespective of vwrap?

Suzy/Pixel

Sent from my iPhone

On Dec 6, 2009, at 6:33 PM, Carlo Wood <carlo at alinoe.com> wrote:

> On Sat, Dec 05, 2009 at 04:30:10PM -0800, Suzy Deffeyes wrote:
>> If the code defaults to the existing hardcoded amazon behavior if a
>> cap to map tiles is not returned, then it doesn't require a LL
>> protocol change.
>
> There will be a time that not all OTHER implementations (ie opensim)
> have implemented this; in which case the cap will fail.
>
> In that case we want to fall back to the OLD way maps worked,
> because that is what works on opensim, at least - on opensim.
>
> Hence, this would require "detection" of on which network
> we are, and then adjust the "protocol" as required...
>
> I just wrote a long post about this horror (believe, it will
> happen again and again and again and the list of this type
> of things will only get LONGER and LONGER!).
>
> What we need, from the very start, is a good protocol
> negotiation sheme added to VWRAP (the new name for OGP).
>
> The protocol negotion sheme that I have proposed would
> make it clear what the base protocol is (the mandatory
> features so to say), as each server implementation gets
> it's own label (ie, LindenLab and OpenSim (as well as
> version numbers of course)). Then you could indeed say:
>
> Hey, opensim doesn't offer the feature "NewMap", so
> we use the old style map. And, hey, LindenLab doesn't
> offer the feature "NewMapURL", so we just use the S3
> url as fall back (for the mandatory "NewMap" feature).
>
> Also, "NewMap" is really optional at the moment (the
> 1.23 viewers don't use it)... If the protocol negotiation
> had already been in place, then LL would have added
> an optional "NewMap" feature, with documentation, at
> the same time that it became available. The 1.23 viewer
> would not have known what it was and wouldn't use it,
> snowglobe would and would use it. THEN, on opensim,
> snowglobe would see that there isn't an optional
> "NewMap" feature and would NOT use the new map style.
>
> This demonstrates the power, and need, for protocol
> negotiation.
>
> At some later date, LL would add support for the new
> map also to the official viewers and make the feature
> mandatory (so that everyone with a client that doesn't
> support it has to upgrade). With the protocol negotiation
> that I proposed, the whole "NewMap" option would disappear
> from the actual negotiation (the documentation would
> still be there though, on the net ;), as if it had
> been a part of the protocol like everything else
> mandatory (ie, support for teleporting).
>
> -- 
> Carlo Wood <carlo at alinoe.com>