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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
