Re: [vwrap] End point "behavior"

[Meadhbh Hamrick <[e-mail]>]

the great thing about standards is there are so many to choose from.

if you want to use the asset and teleport portions of VWRAP without
the seed cap part, go for it.

it's not up to the protocol designers to decide how you wish to deploy
your virtual world services. but clearly if you want to interoperate
with someone who IS using the VWRAP Service Establishment pattern,
you'll have to follow that draft.

this is part of the "we define mechanism, not policy" mantra.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Thu, Sep 23, 2010 at 10:48 AM, Crista Lopes <[e-mail]> wrote:
> On 9/23/2010 9:38 AM, Boroondas Gupte wrote:
>
> I'm not up to date with everything here, so I hope I don't get it completely
> wrong, but here's my take:
>
> On 09/23/2010 05:20 PM, Cristina Videira Lopes wrote:
>
> In other words, if my viewer is in JavaScript, I have to make the JavaScript
> program do things in specific ways, and not others, in order to be able to
> interoperate in VWRAP?
>
> Only regarding what they send and receive over the wire when communicating
> with VWRAP services, I think. The web analog would be that to talk to a web
> server, you have to speak and understand HTTP. Depending on what server it
> is and what you'd like to do with it, there might be additional
> requirements, e.g. WebDAV (just an arbitrary example out of many). What you
> do within the bounds of these protocols and what other processing you do
> (including interfacing non-HTTP resources) is completely up to you.
>
> *According to the drafts*, VWRAP seems to be prescribing specific ways of
> doing the initial user sign in, and specific ways of placing the asset data
> in the user's machine. For sign in, and ignoring what seems irrelevant
> prescriptions that I'm sure will be eliminated, it seems that the client
> must get a seed capability that it then invokes to get more capabilities;
> for asset data, it seems that the VWRAP presciption is to make the server
> send asset capabilities to the client, and then have the client invoke those
> capabilities.
>
> In other words, it looks like my JavaScript program is not going to be
> VWRAP-compliant, and it won't be able to interoperate, if I don't send a
> seed capability from the server to the client at login,  and if I send the
> assets in any way other than via capabilities that the client then invokes
> (for example, sending assets via WebSockets is not VWRAP-compliant (never
> mind whether it's a good idea or not!)). I'm not entirely sure how the asset
> capabilities model maps to VWs that will be streamed.
>
> I'm just trying to understand if this is the case or not, as I work with my
> student on the JavaScript viewer.
>
>
>
>
> Likewise, to talk to a VRAP service, you'll have to speak and understand
> VWRAP.core and, depending on the kind of service and what you want from it,
> the relevant VWRAP.<insert service type here> protocols. What you do within
> the bounds of these protocols and what other processing you do (maybe
> interfacing non-VWRAP resources) is again up to you.
>
> So the "behavior" of the end point only matters in a black-box way: in what
> can be seen from the VWRAP services. Whatever happens inside (or at the
> non-VWRAP sides of the box) is out-of-scope for a communication protocol.
>
> Cheers,
> Boroondas
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>