Re: [vwrap] vwrap Digest, Vol 11, Issue 24

[Mike Dickson <[e-mail]>]

On 03/29/2011 04:42 PM, Katherine Mancuso wrote:
> Hi everyone,
>
> I want to speak up for agreeing with Meadhbh & Mike about keeping a
> role for service level interop in this group.  We've made good
> progress towards this goal and can continue to work on it.
>
> Here is an alternative proposal to any which has been brought up so
> far.  I'm aware this may not be fully correct in its technical
> details, as I am not a software architect:
Just saying up front I'd give this approach a strong +1 from me.  It
recognizes the fact that others are interested in full VW interop while
placing the short term focus on service definition and interaction for
which we have some existing documents and experience that can be
leveraged.   Its a walk before you run approach and personally I think
it would be far more productive in the short term versus the VW interop
approach.
> Could the partisans of "full" VW interop consider working together on
> a draft specification that is something like the intro or David's
> piece in scope that lays out which specific capacities would need to
> be supported at a minimum to allow for "full" interop, perhaps getting
> input from implementers such as the Hypergrid folks and the folks who
> coordinated the teleport test at Linden?  Citing existing service
> specifications (either ones developed within this WG, or outside
> specifications like XML, Collada, etc) is preferred, and for
> capabilities for which there are not existing service specifications
> or the existing specifications don't work well enough, address that to
> lay out a clear roadmap of what must be developed.
>
Again yes, strongly agree.  Full VW interop needs a roadmap to have a
chance to be successful.  At present there are lots of cart paths that
can sort of get you there. And tons of unanswered questions.   Its
valuable to spend cycles on that but not at the expense of specifying
existing services and approaches that work now.

> My vision here is that folks who are doing service-level work could
> continue developing and implementing their individual services, and
> the folks who wish to do "full" interop could define a menu of
> services which must be implemented for "full" interop.  Implementers
> could then choose their path based on their use cases: implement the
> "full" interop specification including all the specifications called
> for, or implement individual services.  I believe that both of these
> concepts can exist under our existing charter or with limited
> amendment to the charter and intro, which is much easier for everyone
> to agree to than entirely rewriting both, and does not require
> trashing years of work.
>
> It seems to me that accomodating "full" interop only would reduce the
> number of possible implementers and use cases for our work
> dramatically, not to mention cut out a productive body of folks in
> this group who have been contributing an awful lot of documents and
> implementing.
>
Yes, again I think thats been what we've seen.  Too little agreement
over a hard problem that limits progress on something for which we do
have some experience.
> For example, to illustrate my point:
>
> From my work as a SL developer focusing in education, I know there's a
> substantial use case in K-12 education in the US for walled gardens,
> because schools have big legal liability problems with letting minors
> wander unwalled virtual worlds (most school libraries in the US have
> internet filters for the same reasons) and have fairly intense
> supervision requirements which require substantial moderation &
> surveillance tools.  However, a shared asset server that contains a
> core of "safe" content might be of interest to these folks, since
> educators don't necessarily need to reinvent the wheel for their
> classrooms every year.  This is a really good case for service level
> interop ... implement the asset server specification only, not the
> "full" one that allows you to teleport to other worlds.
>
> On the other hand, universities have far greater interest in letting
> students and professors teleport among university spaces (which
> happens metaphorically in the real world all the time), and fewer
> liability issues.  Sharing an asset server might be of interest to
> them, but so too might "full" interop.  They'd want to implement the
> "full" interop specification.
>
> (Paging Fleep Tuque, are you here to make this case better for me?)
>
> TL;DR - Proposal is to amend the charter & intro so that they allow
> the "full" interop people to work in one community on their ideas and
> the service level interop people to work in parallel on their ideas,
> rather than assuming that one model has to exclusively dominate the
> group.
>
> I will be unavailable to post anything else much lengthy through 3 April, FYI.
>
> Katherine
>
Well said overall.  I hope teh group gives this approach real consideration.

Mike