Re: [vwrap] End point "behavior" (was: one question)

[Meadhbh Hamrick <[e-mail]>]

also. VWRAP separates "application data" form the transport it's
carried over (like XMPP, HTTP, websockets) and from the form in which
it's serialized (XML, JSON, Binary).

so if you're in a web browser that can't do websockets, you can speak
HTTP and do long poll. there's no requirement in the protocol
specification that a server support websockets over long poll, but
then again, we didn't explicitly require server deployers from
shooting themselves in the foot either.

when we say things like "mechanism, not policy" one of the policies we
think people will have to decide is what services will be accessed
with which protocols.

earlier participants in this group (*cough*lentzner*cough*) advocated
a hands off approach for doing any sort of content or transport
negotiation and just letting individual service providers work out how
to communicate their transport/content encoding decisions to their
clients.

i'm pretty sure i heard pixelq and jhurliman say they would like to
have (at least) a clear description of how to use HTTP status codes to
communicate issues like preferred content encoding.

but.. i think i'm sort of rambling off topic here..

so let me simply re-iterate... yes.. if you use the VWRAP protocol,
your client is expected to be able to interpret messages it receives
and understand the semantics of the messages it sends.

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



On Thu, Sep 23, 2010 at 9:38 AM, Boroondas Gupte
<[e-mail]> 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.
>
> 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
>
>