3 ms·
I upvoted this as it's good to question the assumption and it's easy to imagine this working better without HTTP. In practice though, I feel the project is orde
by mmahemoff 14y ago
I upvoted this as it's good to question the assumption and it's easy to imagine this working better without HTTP. In practice though, I feel the project is orders of magnitude more likely if it's built with HTTP and REST. A social product needs to reach critical mass and any hurdles you're putting in front of users and developers need to be seriously justified. In this case, workarounds like cookies are Good Enough.
- flatline3 14y agoI'd argue that -- for native client authors -- HTTP and REST are actually larger barriers than a simple non-HTTP protocol. I also don't understand the concern over "inventing" a new binary protocol. It's not like it's any more complicated or difficult than "inventing" a non-binary protocol. The framing rules just don't use ASCII/UTF-8 field delimiters. There are plenty of existing encodings to use, no more difficult than JSON.
- TazeTSchnitzel 14y agoOnly if you're using C/C++ and only native OS libraries (or on windows, afraid to use WinHttp for fear of lack of SP1 support)
- flatline3 14y agoMarshalling back and forth between HTTP requests and in-app models via the like of NSURLConnection is far more ugly to do cleanly and efficiently than a simple state machine modeled on message passing over a socket.
- TazeTSchnitzel 14y agoThat's only for Objective-C, it's nicer in Go.