- From: Mark Nottingham <mnot@akamai.com>
- Date: Tue, 20 Mar 2001 11:29:03 -0800
- To: marwan sabbouh <ms@mitre.org>
- Cc: Ray Whitmer <rayw@netscape.com>, xml-dist-app@w3.org
I also support this view. Cheers, On Tue, Mar 20, 2001 at 12:57:47PM -0500, marwan sabbouh wrote: > i view RPC as a module as well, as per my earlier email: > http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0017.html > > we need to close this issue. comments please? > marwan > > Ray Whitmer wrote: > > > > RPC -- is it a module. One last try. > > We had a thread going. Do we need a tighter discussion, such as perhaps > > a phone call today or tomorrow to clarify where we are? I have asked > > before and recall no response to the suggestion for a phone call. > > > > The definition of "module" or "processor" fluctuate day to day, but as I > > implement I continue to see RPC as a module, which exists on client and > > server ends to map the programming environment and language onto the > > SOAP model. > > > > The client and server method within the programming environment may also > > be seen as applications, but the client may be unaware of SOAP, and the > > server is hardly a SOAP handler. They are simply interacting with > > method invocation within the programming environment. The SOAP handler > > is the RPC interpreter which decodes objects and interprets the meaning > > of the method name inside. That a specific URL may permit a specific > > set of RPC calls does not change that RPC is the target, which is > > interpreting the message and selecting from a set of available non-SOAP > > services to dispatch to, based upon method name. That seems rather > > simple to me. > > > > Once we know that, then, are modules permitted to add fault codes such > > as the additional conditions that may be encountered by RPC? How? > > > > Ray Whitmer > > rayw@netscape.com -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA)
Received on Tuesday, 20 March 2001 14:29:06 UTC