Re: [ogpx] [sldev] Snowglobe on OpenSim grids

I honestly can't imagine why we wouldn't. Hard coded singletons are 
totally silly in a world that's growing towards interoperability. 
- David
~ Zha

Dahlia Trimble <dahliatrimble@gmail.com> 
Sent by: ogpx-bounces@ietf.org
12/09/2009 03:27 AM

To
"sldev@lists.secondlife.com" <sldev@lists.secondlife.com>
cc
"ogpx@ietf.org" <ogpx@ietf.org>
Subject
Re: [ogpx] [sldev] Snowglobe on OpenSim grids

Along the same lines of the hard coded map URL, there's one other URL that 
I'm aware of that appears to be hard coded: the search pages. Could 
similar logic that's been discussed so far for the map be applicable for 
search as well? Or is there a better solution?

-Dahlia

On Tue, Dec 8, 2009 at 5:23 AM, Suzy Deffeyes <suzyque@gmail.com> wrote:
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@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@alinoe.com>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting 
privileges
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx