[sldev] [ogpx] Snowglobe on OpenSim grids
Joshua Bell
josh at lindenlab.com
Wed Dec 9 11:17:39 PST 2009
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20091209/1dfca131/attachment-0001.htm
More information about the SLDev
mailing list