[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Date | Thread | Author

[XML-SIG] WSDL library ?

> So can HTTP and SMTP, using extension headers.    (01)

You don't like the invention of SOAP but you accept an invention of new
HTTP headers? :)    (02)

>  BEEP doesn't even need extensions, I think.    (03)

Beep solves different problems, it's HTTP-NG, really; a plea in the
night that we avoid crappy substrates like HTTP.    (04)

> >       - SOAP with Attachments
>> I thought you were listing reasons for liking SOAP.  I'm unable to interpret
>> this as such.    (05)

id/ref and the CID scheme; perhaps more accurate: "it makes SwA
possible."    (06)

> >       - Ability to send XML
>> Anything can send XML.  And SOAP/RPC is very lexically brittle for sending XML
>> has serious problems sending XML.  For instance, if the embedded XML has an
>> XML decl, you have to escape things.    (07)

XML embedded in XML is a general XML problem.  You can't send XML in
XML-RPC unless you stringify it.  If I've already got a message decoder,
why force the price of re-encapsulation.    (08)

> And anyway, why can't anything else send XML?    (09)

See above.    (010)

> This is not an absolute statement.  A CORBA person would tell you that given
>> structs, ANYs, object-by-value, etc., CORBA is every bit as rich in data types
>> as SOAP/RPC.    (011)

And since Corba doesn't have pointers, that person would be wrong.    (012)

> Can you give a concrete example of a task that SOAP's data typs made more
>> possible than if you'd used other RPC mechanisms?    (013)

Ahh, that's a different question.  Are there equivalent tools? 
Certainly. Is that really the key problem?  It seems like your position
	If it's simple use XML-RPC; if it's not, use Corba
Is that fair?  If so, then what about all those DCOM and pure-RPC and
java-RMI folks?    (014)

> And why can't you send hrefs using any other mechanism?    (015)

Sure, if you can define a datatype that is "aliasable."  But I was
trying to show what I liked about SOAP that wasn't in other things, not
what I liked that could be created elsewhere.    (016)

> >       - reasonable size to implement
>> Having looked really closely at ZSI, SOAP.py, SOAPy, and our own coupel of
>> attempts to implement, I am astounded at this claim.    (017)

I guess we come at it from different viewpoints.  I wrote a C++ BER
library for LDAP; it took 2000 lines.  A full DER package such as
openssl's ASN1 module is 18K lines. The core SOAP part of ZSI (TC*.py,
parse.py, writer.py) is 2K lines.  DCE RPC was like 25K lines.    (018)

> * SOAP interoperability is a myth, as I can painfully attest    (019)

Disagree, as I can attest. :)  Come join us in the soapbuilders mailing
list (at yahoogroups).    (020)

> Funny thing is that Clay Shirky makes a completely different set of points from my own, and still manages to roast WS quite handily    (021)

Yes, I quite enjoy Clay's writing.  SOAP != web services.    (022)

And IIOP is a crappy protocol that only came into existence because Sun
said DCE protocol over my dead body and IBM, fearing DCOM, caved in.  If
it were so great, RMI would've gone along quietly. :)
	/r$    (023)

Zolera Systems, Securing web services (XML, SOAP, Signatures,
http://www.zolera.com    (024)