Jon Smirl wrote:
>
> Should XPCOM introduce the concept of asynchronous calls?
There is some async support in the xpcom/proxy stuff. WE don't
plan to use that. Async calling is not something that you can
really do transparently - binding multiple out params and all
that.
The scheme that we've discussed for the SOAP support is to
generate both sync and async method entries in our generated
interfaces. So, if a given web service has two entry points we'd
generate an interface with 4 entry points.
Something like...
// MyService has foo and bar...
// nsISOAPCallContext is a generic interface that lets us
// track the call progress and cancel it etc.
// Callers to the *Async MyService methods must implement
// this interface to receive call results. The SOAP system
// will hold a reference to this object and call the
// associated method with the result of the call when the
// service returns.
[scriptable, uuid(..)]
interface nsISOAP_MyService_Response : nsISupports
{
void callFailed(in nsISOAPCallContext context);
void fooResponse(in nsISOAPCallContext context,
in PRUint32 foo_retval);
void barResponse(in nsISOAPCallContext context,
in PRUint32 bar_retval,
in string outString);
};
// The MyService declaration with sync and async
// entry points for foo and bar.
[scriptable, uuid(..)]
interface MyService : nsISupports
{
PRUint32 foo();
nsISOAPCallContext fooAsync(
in nsISOAP_MyService_Response callback);
PRUint32 bar(
in string inString,
out string outString);
nsISOAPCallContext barAsync(
in string inString,
in nsISOAP_MyService_Response callback);
};
> Could SOAP be used to solve the problem of interprocess XPCOM?
Well. It *could*. But it is not really optimized for the sorts of
things that people might want to do with IPC. For one, we are not
seeing much reason to build a SOAP server in mozilla. That leaves
you needing to do that and deal with all this nice XML stuff.
Perhaps more importantly, we are building a system that passes
all data by value and no data by reference. This means no proxies
(other than the service object proxy) get built. No callback
event from the server. Mostly this is because (most) SOAP is to
http servers and so many real world clients can't be web servers
that we don't think many folks will want to build apps that
assume that their clients can field http requests.
This relieves us of the burden of distributed gc and the ugliness
of the mechanisms that make these schemes work.
We think that systems using SOAP will be constructed with the
understanding that it is better to make few calls with big chunks
of data and anticipating high latency rather than expecting to be
able to make frequent quick calls - as people using 'transparent'
distributed object systems often hope for.
>
> Integrating SOAP into XPCOM's philosophy could be the beginnings of a
> Mozilla reply to dot net.
I don't have a lot to say about that. The Web is based on the
idea of universal access. I think innovation should be in the
context of open standards. I think people will want to build
applications that include clients to web services. Mozilla - and
other Web clients - ought to support that.
John.
>
> --
> Jon Smirl
> [EMAIL PROTECTED]
