[sldev] [ogpx] Snowglobe on OpenSim grids

Philippe (Merov) Bossut merov at lindenlab.com
Wed Dec 9 19:00:58 PST 2009


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 <josh at lindenlab.com> 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 <dwl at us.ibm.com> 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 <dahliatrimble at gmail.com>*
>> Sent by: ogpx-bounces at ietf.org
>>
>> 12/09/2009 03:27 AM
>>   To
>> "sldev at lists.secondlife.com" <sldev at lists.secondlife.com>
>> cc
>> "ogpx at ietf.org" <ogpx at 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 at gmail.com*<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*<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* <carlo at alinoe.com>>
>> _______________________________________________
>> 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
>> ogpx at ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx at ietf.org
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091209/69ceb96c/attachment.htm 


More information about the SLDev mailing list