3 ms·

Sounds like we may be getting another name or acronym to add to the long list of failed technologies that have already tried to promote a similar idea. We alre

Sounds like we may be getting another name or acronym to add to the long list of failed technologies that have already tried to promote a similar idea. We already have ONC RPC, DCE, Java's Remote Method Invocation, Jini, CORBA, SOAP, and .NET Remoting, among many others. Does this family of failure really need to grow any larger?

jerf 14y ago
No, this is about how the libraries that bind to HTTP don't actually match HTTP's model of operation. I've banged on this drum in a couple of cases myself with framework authors, in some cases even right at the beginning of the framework's life, and generally hit a brick wall. HTTP is not a request/response protocol. It certainly once was back in HTTP/1.0, but with pipelining and reusing connections and now websockets (and soon SPDY's server push/hint), it's a streaming protocol that has a common use case where it is used for request/response, and that requires a completely, completely different API than a protocol that is truly request/response. It is a lot easier to build a streaming base that has a special case for request/response than it is to build a request/response base and then hack in bizarre conceptually-impure bullshit for streaming, but every web framework I can find is the latter, if indeed they don't simply punt entirely on streaming because they've written it so thoroughly out of the API. (I'm vaguely aware of some that are actually sensible but all in languages I don't know and haven't gotten to yet, so I'm not sure if they really are built on a sensible base or if it merely raises the bizarre crap to API-blessed status.)
- saurik 14y ago
  Can you describe this further? Reading this guy's post it sounds like he's complaining about the exact opposite problem: that the web framework is designed for streaming and, despite that I agree with you that specializing request/response out of that should be easy, he claims that this seems to make it awkward or impossible for him to have his request/response model.
the_mitsuhiko 14y ago
> We already have ONC RPC, DCE, Java's Remote Method Invocation, Jini, CORBA, SOAP, and .NET Remoting, among many others. Does this family of failure really need to grow any larger? Just that what we're doing is nothing of that. It's plain old HTTP with JSON. The implementation on the server side is the difference.

jerf 14y ago

No, this is about how the libraries that bind to HTTP don't actually match HTTP's model of operation. I've banged on this drum in a couple of cases myself with framework authors, in some cases even right at the beginning of the framework's life, and generally hit a brick wall. HTTP is not a request/response protocol. It certainly once was back in HTTP/1.0, but with pipelining and reusing connections and now websockets (and soon SPDY's server push/hint), it's a streaming protocol that has a common use case where it is used for request/response, and that requires a completely, completely different API than a protocol that is truly request/response. It is a lot easier to build a streaming base that has a special case for request/response than it is to build a request/response base and then hack in bizarre conceptually-impure bullshit for streaming, but every web framework I can find is the latter, if indeed they don't simply punt entirely on streaming because they've written it so thoroughly out of the API. (I'm vaguely aware of some that are actually sensible but all in languages I don't know and haven't gotten to yet, so I'm not sure if they really are built on a sensible base or if it merely raises the bizarre crap to API-blessed status.)

saurik 14y ago
Can you describe this further? Reading this guy's post it sounds like he's complaining about the exact opposite problem: that the web framework is designed for streaming and, despite that I agree with you that specializing request/response out of that should be easy, he claims that this seems to make it awkward or impossible for him to have his request/response model.

the_mitsuhiko 14y ago

> We already have ONC RPC, DCE, Java's Remote Method Invocation, Jini, CORBA, SOAP, and .NET Remoting, among many others. Does this family of failure really need to grow any larger? Just that what we're doing is nothing of that. It's plain old HTTP with JSON. The implementation on the server side is the difference.