Re: [vwrap] End point "behavior"

[Crista Lopes <[e-mail]>]

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
>