Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds

[Morgaine <[e-mail]>]

On Sat, Jul 25, 2009 at 4:11 AM, David W Levine <[e-mail]> wrote:

>
> In general, the entire flavor of the specifications is "You start here, and
> you get handed back details about how the services you want to access are
> deployed. In particular, the capabilities mechanism is very good at
> permitting a deployment to map its services onto network endpoints as it
> sees fit. There are a few, necessarily fixed starting points, from which the
> dance begins, but, the overall pattern is authenticate, ask for services,
> and get handed short term use capabilities to access those services. Since
> the protocols and the design don't dictate any requirement that that the
> capabilities be serviced on the machine where a client made the request, we
> get a lot of flexibility.



That's an excellent approach, and I'd say *mandatory*, given that we don't
know what the future holds in this rapidly changing scene and we don't want
to paint ourselves into a corner.  Flexibility is crucial, and service
endpoint mapping (for want of a better term) provides much flexibility.

To put a little more meat on the bones, could you please describe how you
see this endpoint mapping working in the area of asset and inventory
services (A+IS)?  A rough sketch to get us started will do, acknowledging
that an actual spec does not yet exist for it.

Also, could you please mention how A+IS endpoint mapping might provide or
aid flexibility in transferred asset data types?  This is an area of very
rapid change, with new data types being continually suggested and created,
and therefore hardwiring of types would almost immediately paint us into a
corner of obsolesence.  (I believe I know your answer to this one, given the
REST approach, but please summarize it again here, since it has not yet been
mentioned on this list and we have new membership.)

Regards,

Morgaine.








On Sat, Jul 25, 2009 at 4:11 AM, David W Levine <[e-mail]> wrote:

>
> Infinity mentioned this, and I thought I'd chime in and agree. The OGPX
> specifications are built to be incremental. All of the coding work I've done
> using early versions of the specs confirms this. In fact, the biggest
> challenge probably isn't going to be permitting incremental change and
> experimentation, but making sure that we put in enough (and not too much)
> stuff to manage the consequences of the flexibility.
>
> In general, the entire flavor of the specifications is "You start here, and
> you get handed back details about how the services you want to access are
> deployed. In particular, the capabilities mechanism is very good at
> permitting a deployment to map its services onto network endpoints as it
> sees fit. There are a few, necessarily fixed starting points, from which the
> dance begins, but, the overall pattern is authenticate, ask for services,
> and get handed short term use capabilities to access those services. Since
> the protocols and the design don't dictate any requirement that that the
> capabilities be serviced on the machine where a client made the request, we
> get a lot of flexibility.
>
> That said, we have no desire to re-create a general distributed computing
> fabric. The bulk of the specifications are about the bits we believe we need
> to move to support virtual worlds, not the details of moving those bits.
> There has been a fair bit of real thinking about how the design patterns are
> laid out so that you *could* deploy the protocol sequences over different
> messaging layers than the http(s)  The number of actual RESTish web service
> deployments over XMPP, RTP, or other plausible messaging oriented protocols
> is pretty small. My personal take is that we have covered most of the bases,
> but that any real world deployment of the OGPX specifications over  a
> protocol such as XMPP would require a specific RFC on the exact adaptation,
> and I wouldn't be shocked if it tripped over at least one hidden assumption
> in the current design. We're trying very hard to stay focused on specifying
> from working code, with an eye to the future, not the other way around.
>
> - David W. Levine
> ~ Zha Ewry (In Second Life)
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>