RE: how bad is soap?

["Patrick R. Gili" <pgili@cisco.com>]

> Patrick> I don't think its a matter of complexity so much as a matter
> Patrick> of return on the investment.
>
> Interoperability with _existing_ implementations is I think a good
> return on investment, but your mileage might vary.

	Existing implementations of what? Has someone implemented
	XMLCONF (or NETCONF, or whatever we're calling it today)?
	I would not think that interoperability would be an issue
	at this point.

>
> Patrick> First, the SOAP header can become quite large and verbose.
>
> I believe the SOAP header will be small relative to the data portion
> if we continue the approach to move configurations around as opaque
> XML or text blobs with a rather limited set of operations.

	In my experience, the SOAP header will exceed the size of
	most configuration operations.

>
> Patrick> Second, one of the reasons for using XML is
> Patrick> human-readability; that is, it eases the process of
> Patrick> development, debugging and maintenance without requiring
> Patrick> special tools and utilities.  Have you tried to read a SOAP
> Patrick> header lately?  Argh.
>
> SOAP uses XML for the encoding - do you see the contradiction in your
> statement? Anyway, looking at the examples in <http://www.w3.org/TR/SOAP/>,
> I am not yet sure that the header has much more complexity compared to
> what xmlconf might end up with (unless xmlconf decides to ignore
> namespaces, which might be a mistake).

	I realize that the SOAP encoding is XML.  However, I've seen
	some down-right ugly to read SOAP headers.

Observe that I am not presenting an argument against using SOAP.
I just want to make sure that we talk through all the salient
points of why or why not to employ SOAP for the purposes of
this solution.



--
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/>