[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: how bad is soap?



At 01:13 PM 4/24/2003, Durham, David wrote:

>I agree with John and Juergen. Let s not reinvent the wheel unless we can prove beyond any doubt that the existing wheel needs reinventing. The onus isn t on Juergen, it is on those saying SOAP isn t acceptable. The reason should at least be provable, because there is tendency in this standards body to reinvent w/o good reason. 

Until somebody publishes an I-D that explains exactly what
problems the as-yet-unspecified subset of SOAP is attempting to solve,
we cannot take this non-proposal seriously.  Cliches like
"reinventing the wheel" are meaningless. You have to precisely
explain what problems in the netconf charter are being addressed.
Examples of protocol message exchanges are also helpful to
vendors and operators in determining the cost/benefit ratio
of the proposal. 


> 
>
>-Dave

Andy



> 
>
>-----Original Message-----
>From: John Strassner [mailto:John.Strassner@intelliden.com] 
>Sent: Thursday, April 24, 2003 1:04 PM
>To: 'Patrick R. Gili'; John Strassner; 'Juergen Schoenwaelder'
>Cc: xmlconf@ops.ietf.org
>Subject: RE: how bad is soap?
>
> 
>
>To fill its role as a generic standard. Don't confuse genericity with efficiency for a targeted implementation. ;-)
>
> 
>
>regards,
>John
>
>John Strassner
>Chief Strategy Officer
>Intelliden Corporation
>90 South Cascade Avenue
>Colorado Springs, CO  80903  USA
>phone: +1.719.785.0648
>  FAX: +1.719.785.0644
>email: john.strassner@intelliden.com
>  
>
>-----Original Message-----
>From: Patrick R. Gili [mailto:pgili@cisco.com] 
>Sent: Thursday, April 24, 2003 1:58 PM
>To: John Strassner; 'Juergen Schoenwaelder'
>Cc: xmlconf@ops.ietf.org
>Subject: RE: how bad is soap?  
>Hi John, 
>  
>If all these headers are optional, what purpose does SOAP serve? 
>Again, it comes back to this notion of "return on investment". 
>  
>Patrick Gili 
>-----Original Message----- 
>From: John Strassner [mailto:John.Strassner@intelliden.com] 
>Sent: Thursday, April 24, 2003 3:48 PM 
>To: 'Juergen Schoenwaelder'; pgili@cisco.com 
>Cc: xmlconf@ops.ietf.org 
>Subject: RE: how bad is soap? 
>I'll join Juergen in this role at well. It appears that SOAP is more misunderstood than it is understood. Headers are optional, and again, there's no reason why you can't use existing SOAP mechanisms (i.e., mustUnderstand) to cut down the clutter. You could also choose to support a subset of SOAP. 
>After talking privately with Bert, here's the offer TO NETWORK OPERATORS on this list: 
>
>  If there is sufficient interest from NETWORK  
>  OPERATORS in seeing what the advantages of  
>  WSDL and SOAP (and possibly UDDI) have in  
>  simplifying configuration management, then  
>  I will organize a group to write an I-D and  
>  have it published in time for the Vienna  
>  meeting. If not, have a nice day. ;-) 
>
>regards,  
>John  
>   
>John Strassner  
>Chief Strategy Officer  
>Intelliden Corporation  
>90 South Cascade Avenue  
>Colorado Springs, CO  80903  USA  
>phone: +1.719.785.0648  
>  FAX: +1.719.785.0644  
>email: john.strassner@intelliden.com  
>  
>
>  
>-----Original Message-----  
>From: Juergen Schoenwaelder [<mailto:schoenw@ibr.cs.tu-bs.de>mailto:schoenw@ibr.cs.tu-bs.de]  
>Sent: Thursday, April 24, 2003 9:59 AM  
>To: pgili@cisco.com  
>Cc: xmlconf@ops.ietf.org  
>Subject: Re: how bad is soap? 
>
>  
>>>>>> Patrick R Gili writes: 
>
>Patrick> Existing implementations of what? Has someone implemented  
>Patrick> XMLCONF (or NETCONF, or whatever we're calling it today)?  I  
>Patrick> would not think that interoperability would be an issue at this  
>Patrick> point. 
>
>I was just saying that using an existing RPC mechanism has the advantage that there are existing implementations to interface with. 
>Patrick> In my experience, the SOAP header will exceed the size of most  
>Patrick> configuration operations. 
>
>Fine. We might have different environments in mind and we do not have to agree. 
>
>Patrick> I realize that the SOAP encoding is XML.  However, I've seen  
>Patrick> some down-right ugly to read SOAP headers. 
>
>I assume you mean SOAP headers as defined in section 4.2 of the SOAP 1.1 specification as follows: 
>
>: SOAP provides a flexible mechanism for extending a message in a  
>: decentralized and modular way without prior knowledge between the  
>: communicating parties. Typical examples of extensions that can be  
>: implemented as header entries are authentication, transaction  
>: management, payment etc.  
>:  
>: The Header element is encoded as the first immediate child element of  
>: the SOAP Envelope XML element. All immediate child elements of the  
>: Header element are called header entries. 
>
>Sure, if you put complexity there such as authentication machinery, then header becomes longer and harder to read. But will it be substantially different from an xmlconf over beep message with apropriate security? 
>Patrick> Observe that I am not presenting an argument against using  
>Patrick> SOAP.  I just want to make sure that we talk through all the  
>Patrick> salient points of why or why not to employ SOAP for the  
>Patrick> purposes of this solution. 
>
>Sure, I also just want to make sure we understand why existing RPC mechanisms simply do not work here and why the costs for a new special purpose RPC mechanism are well justified. And to really get there, I think someone has to play devils advocate and right now, it looks like I end up having this role. ;-) 
>/js 
>
>--  
>Juergen Schoenwaelder           International University Bremen  
>Phone: +49 421 200 3587         P.O. Box 750 561, 28725 Bremen, Germany  
>Fax:   +49 421 200 3103         <<http://www.iu-bremen.de/>http://www.iu-bremen.de/> 
>
>--  
>to unsubscribe send a message to xmlconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. 
>archive: <<http://ops.ietf.org/lists/xmlconf/>http://ops.ietf.org/lists/xmlconf/> 


--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>