Hi, +1 on Josh's proposal. This is certainly something we should be doing though, clearly, there's work server side as for what that cap is and returns... So, server folks, please shoot first :)
In the meantime, on the client side, we can prepare this. There's only one occurrence of the guilty string (in llworldmipmap) and LLWorldMipmap seems to be the right class to introduce a getURLFromPosition(U32 grid_x, U32 grid_y, S32 level) that would implement Josh's pattern. There is already a SNOW bug mind you to cover this though it was written in the context of the aditi grid: https://jira.secondlife.com/browse/SNOW-77 More detailed proposals (and hopefully patches... :) ) should be added in that PJIRA. Cheers, - Merov On Wed, Dec 9, 2009 at 11:17 AM, Joshua Bell <[email protected]> wrote: > Dropping the IETF list... > > Even in lieu of Linden exposing caps for map services (or search, or...), > it is reasonable to prototype the implementation of such services and > integrate support for those services into Snowglobe. > > (Disclaimer: when I write "cap" here I'm talking generally about service > endpoints which may or may not be cryptographically generated and > permission-based.) > > The typical pattern has been to take client (pseudo-)code such as this: > > use_hardcoded_endpoint_for_foo(); > > And replace it with: > > if (has_cap_for_foo) > use_cap_for_foo(); > else > use_hardcoded_endpoint_for_foo(); > > When all service providers are generating the cap, the hardcoded client > code can optionally be removed (a cause for celebration). > > (In practice the code structure is usually gnarlier, since we're not > talking about swapping URLs but replacing a custom UDP request/response > protocol that may not be clearly factored with a nicely encapsulated HTTP > request/response model. But logically, it's the same.) > > If we determine that the cap needs to change - perhaps the prototyped > design can't be adopted as-is by Linden for some reason, or the cap is rev'd > in some incompatible way (even given the version skew-combating super-powers > of LLSD), then the client code would be updated to be: > > if (has_cap_for_foo2) > use_cap_for_foo2(); > else if (has_cap_for_foo) > use_cap_for_foo(); > else > use_hardcoded_endpoint_for_foo(); > > (And ideally the client code that embodies this logic is nicely > encapsulated so that these tests aren't repeated. Regardless, this is an > extremely common pattern for exactly this capability-probing situation.) > > Suzy asks: "Can we make a simple fix for OpenSim now that will still work > with the existing Linden grid, irrespective of vwrap?" > > I would suggest: yes! > > (1) Implement the cap on the server side > (2) Implement the client side code to use it > (3) Share the design here/JIRA for community review > (4) Push the patch to Snowglobe via JIRA > (5) If the client needs to support a different cap in the future e.g. for > Linden, the model above would be followed. > > On Wed, Dec 9, 2009 at 7:08 AM, David W Levine <[email protected]> wrote: > >> >> 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 <[email protected]>* >> Sent by: [email protected] >> >> 12/09/2009 03:27 AM >> To >> "[email protected]" <[email protected]> >> cc >> "[email protected]" <[email protected]> >> 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 >> <*[email protected]*<[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]*<[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]* <[email protected]>> >> _______________________________________________ >> Policies and (un)subscribe information available here:* >> **http://wiki.secondlife.com/wiki/SLDev*<http://wiki.secondlife.com/wiki/SLDev> >> Please read the policies before posting to keep unmoderated posting >> privileges >> _______________________________________________ >> ogpx mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ogpx >> >> >> _______________________________________________ >> ogpx mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/ogpx >> >> > > _______________________________________________ > 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
