The S stands for Simple • Hacker News Board

Re: The S stands for Simple

#21

Post by sgk284 » Tue, Dec 15, 2009, 9:43 AM UTC

sketerpot wrote: post #3

Did anybody else hear the SOAP Guy's lines in a voice that sounds like a cross between a used car salesman and Foghorn Leghorn? Also, I like Google's protocol buffers library. It's straightforward, fast, has really nice bindings for C++, Java, and Python, and we know it's stable because it's what Google uses for most of its internal RPC stuff. http://code.google.com/p/protobuf/

Yea, but the PB library doesn't actually handle sending requests over the network, etc... It literally just encodes data. If you like protocol buffers, check out Thrift. Thrift was designed based off of protocol buffers, but handles everything from end to end. http://incubator.apache.org/thrift/

Re: The S stands for Simple

#22

Post by blasdel » Tue, Dec 15, 2009, 10:03 AM UTC

seldo wrote: post #8

I have to say that SOAP didn't even seem like a good idea at the time.

Dave Winer: Menace, or Monster?

Re: The S stands for Simple

#23

Post by papaf » Tue, Dec 15, 2009, 10:08 AM UTC

I'm sure I've had this conversation in real life :-) My one experience with SOAP was trying to get a perl client library working with a Java server -- they weren't compatible with each other. In the end I used ethereal with a Java client and dumped the request which I could then replay through perl. In fact, I would go as far to say SOAP is the least fun protocol that I've ever used (including an undocumented one).

Re: The S stands for Simple

#24

Post by houseabsolute » Tue, Dec 15, 2009, 10:16 AM UTC

sgk284 wrote: post #21

sketerpot wrote: post #3

Did anybody else hear the SOAP Guy's lines in a voice that sounds like a cross between a used car salesman and Foghorn Leghorn? Also, I like Google's protocol buffers library. It's straightforward, fast, has really nice bindings for C++, Java, and Python, and we know it's stable because it's what Google uses for most of its internal RPC stuff. http://code.google.com/p/protobuf/

Yea, but the PB library doesn't actually handle sending requests over the network, etc... It literally just encodes data. If you like protocol buffers, check out Thrift. Thrift was designed based off of protocol buffers, but handles everything from end to end. http://incubator.apache.org/thrift/

To be more specific, the protocol buffer library provides an interface for transport, but not the transport layer itself.

Re: The S stands for Simple

#25

Post by balakk » Tue, Dec 15, 2009, 10:45 AM UTC

psadauskas wrote: post #9

Its been my experience that anything with Simple or Lightweight as one of the letters in the acronym is usually anything but.

S3 , SimpleDB are not all that bad.

Re: The S stands for Simple

#26

Post by steve_g » Tue, Dec 15, 2009, 11:46 AM UTC

three14 wrote: post #15

If you know that you're only going to be using the Microsoft stack, and you actually do get to use the tools that cover all this up, do you still end up regretting that there's SOAP under all of it? I've just found myself working on a project like that for the first time, and saw this, and started wondering.

If both ends of the communication are on the Microsoft stack, setting up SOAP webservices is straightforward. The tools basically take care of everything. In our case, we have a customer who exposed an ASP.NET webservice that we consume (data flows in both directions). Our production apps use VB.NET to hit the webservice, but I was able to easily write a python client for testing (by handrolling the SOAP messages).

My intuition is that SOAP starts becoming unpleasant if you have lots of parties involved and/or multiple platforms. We haven't hit that wall.

Re: The S stands for Simple

#27

Post by blasdel » Tue, Dec 15, 2009, 12:14 PM UTC

antonovka2 wrote: post #12

jcapote wrote: post #7

Earlier quoted context omitted.

bert-rpc.org

I hope not. Between Protobuf and Thrift, I don't see the point of adopting a less efficient, even more niche NIH serialization format and RPC protocol.

Both protobuf and Thrift are designed exclusively around simple static type-checking with type-erasure. Neither support heterogeneous collections, much less discriminated unions or GADTs.

There are plenty of untaken vertices in the serialization-format hypercube.

Re: The S stands for Simple

#28

Post by shin_lao » Tue, Dec 15, 2009, 1:10 PM UTC

sketerpot wrote: post #3

Did anybody else hear the SOAP Guy's lines in a voice that sounds like a cross between a used car salesman and Foghorn Leghorn? Also, I like Google's protocol buffers library. It's straightforward, fast, has really nice bindings for C++, Java, and Python, and we know it's stable because it's what Google uses for most of its internal RPC stuff. http://code.google.com/p/protobuf/

It's a good library, I've used it extensively. I only wish it would generate less warnings at compile time. :)

Re: The S stands for Simple

#29

Post by bsaunder » Tue, Dec 15, 2009, 1:32 PM UTC

10ren wrote: post #4

Interoperability is a vitally important but hard problem. CORBA and then SOAP have been thoroughly adopted, then widely condemned. What's next?

I like the MQ stacks (particularly ActiveMQ). I've used a proprietary message bus in the past and it was really nice to just send and receive message at the application level. Of course migrating to an asynchronous model of development can be challenging for some.

Re: The S stands for Simple

#30

Post by mgrouchy » Tue, Dec 15, 2009, 1:51 PM UTC

I can identify with this totally. This was my life like 4 months ago before I started at the startup I am working at now.

Trying to write these schemas by hand IS hell, but putting blind trust in your toolbox is possibly even worse.