[sldev] Snowglobe on OpenSim grids

[Dahlia Trimble]

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 at 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 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>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091209/87122eab/attachment.htm