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

RE: mustUnderstand on client side

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Wed, 2 May 2001 20:48:51 +0100
Message-ID: <5E13A1874524D411A876006008CD059F1923FC@0-mail-1.hpl.hp.com>
To: "'frystyk@microsoft.com'" <frystyk@microsoft.com>, "'Doug Davis'" <dug@us.ibm.com>
Cc: Noah_Mendelsohn@lotus.com, dick@8760.com, xml-dist-app@w3.org
> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:frystyk@microsoft.com]
> Sent: 02 May 2001 19:40
> To: 'Williams, Stuart'; 'Doug Davis'
> Cc: Noah_Mendelsohn@lotus.com; dick@8760.com; xml-dist-app@w3.org
> Subject: RE: mustUnderstand on client side
> 
> You probably want to avoid fault storms. However, as SOAP doesn't say
> where to send a fault, this restriction seems to be more targeted a
> routing module than the base SOAP protocol.

Hmmm... maybe. However, a routing module is unlikely to be able to determine
that a fault that it is being asked to 'route' arose during the processing
of another fault and hence 'supress' the transmission of the message. How
would a routing module recognise those faults that it needed to route and
those that it needed to drop? Surely, its is the processor processing the
original fault that is best placed to exercise self-restraint!

> >I also think we should give some thought to what should happen 
> >if an XMLP processor faults while processing a fault message! 
> >Missing details can lead to melt down :-)
> 
> Henrik 

Stuart
 
Received on Wednesday, 2 May 2001 15:49:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:01 GMT