W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2001

RE: Draft Alternate Section 3.

From: Krishna Sankar <ksankar@cisco.com>
Date: Mon, 26 Mar 2001 08:44:04 -0800
To: "Jean-Jacques Moreau" <moreau@crf.canon.fr>
Cc: "Williams Stuart" <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>

	Good ideas. I was really thinking of "protocol binding" but "protocol
conversion" does offer possibilities.

	Just on the subject, I see XMLP used in netServices not just webServices.
Even though SOAP/http might be the norm now, nothing should stop us using
XMLP over other mechanisms.

	IMHO, if an application (be it be in a net widget or a web browser or a
refrigerator which talks some device protocol like JINI or ..) understands
the syntax and semantics of XMLP, it should be able to converse through as
many underlying "protocols" as possible.


|-----Original Message-----
|From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
|Behalf Of Jean-Jacques Moreau
|Sent: Monday, March 26, 2001 1:40 AM
|To: Krishna Sankar
|Cc: Williams Stuart; xml-dist-app@w3.org
|Subject: Re: Draft Alternate Section 3.
|Krishna Sankar wrote:
|>         9.      "This operation may be implemented over HTTP,
|> SMTP" : Why not RMI, COM+ et al ? The point is do we *need to*
|> assume/specify any protocol/transport ? Of course, we would have the
|> bindings and hopefully we could specify bindings to these as well.
|Using RMI or COM+ as an underlying transport protocol (ie, to
|transport XMLP enveloppes
|verbatim) seems a bit far-fetched (don't these protocols already
|include the machinery that
|XMLP is about to define?). On the other hand, I can see why you
|would map XMLP enveloppes to
|RMI/COM+ requests. But then, we are probably talking about
|"protocol conversion" rather than
|about "protocol binding".
Received on Monday, 26 March 2001 11:45:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:12 UTC