[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XMLCONF Proposal
[ post by non-subscriber. with the massive amount of spam, it is easy to miss
and therefore delete posts by non-subscribers. if you wish to regularly
post from an address that is not subscribed to this mailing list, send a
message to <listname>-owner@ops.ietf.org and ask to have the alternate
address added to the list of addresses from which submissions are
automatically accepted. ]
Hi!
Harrie> Why using RPC and not for instance SOAP over HTTP??
Phil> There are a number of reasons. The ones that pop into
Phil> my head are:
Phil> SOAP lacks the connection-oriented aspect we've found
Phil> simplifies locking, debugging, and session recovery.
Phil> Using HTTP/HTTPS makes firewalling more difficult.
Phil> We needed multiple channels for control and notifications.
Phil> The benefits of XMLCONF wrapped in SOAP wrapped in HTTP/HTTPS
Phil> weren't clear to us.
I believe these are HTTP characteristics and not general SOAP
problems.
Did you investigate to which degree the XMLCONF requirements can be
- generally adressed by SOAP (without having any SOAP transport in
mind), and
- specifically efficiently addressed by SOAP-over-BEEP (RFC 3288)?
I'm not sure whether I would really vote for SOAP, but I comprehend
Harrie's question, since SOAP and WSDL are already there and the
XMLCONF work could probably be limited to service definitions based on
WSDL while the current proposal defines yet another protocol (or BEEP
profile, respectively).
While today people claim about the complications and pitfalls when
they have to design and implement MIBs, maybe tomorrow, they would ask
why they have to handle those XML documents that represent RPC
requests and responses, although there is are standards and toolkits
that would have made all that much easier.
-frank
--
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/>