Earlier quoted context omitted.
> Yes, TCP streams are very complicated to work with (in my experience) -- there are way too many failure modes and corner cases to consider. Isn't it the same thing, but simpler and more flexible? You write a message, and then you read a reply, rinse and repeat. Could you expand on such things that are complicated with TCP that HTTP helps with?
When you're working with sockets there's lots to think about that you can simply ignore with an HTTP library -- connection setup and teardown, buffering, serialization, byte ordering etc. But more importantly, you'll have to build your own status/error handling, cache control, content encoding, TLS etc. (Simply, doing TLS correctly itself is not easy.) To be clear, I'm not saying that there's no place for socket prog…
> connection setup and teardown
If there's no benefit in avoiding setting up and tearing down a connection with each request like one typically does with HTTP, then I can see how it might be an annoyance compared to making a single function call from a library that makes the request and returns the response.
> buffering
A parser should deal with that. It could be JSON parser.
> serialization
That's still a problem with HTTP. People typically use JSON for this and it doesn't depend on HTTP.
> byte ordering
parser/JSON's job.
> your own status/error handling, cache control, content encoding
That can be beneficial or it can be problematic. If you need such things, then yeah, it's cool to not have to think about making your own. However, if you don't or if your needs don't align with what HTTP provides, that can be problematic. For example, from a cursory search I see the following in the JMAP spec:
> Implementors must take care to avoid inappropriate caching of the session object at the HTTP layer. Since the client should only refetch when it detects there is a change (via the sessionState property of an API response), it is RECOMMENDED to disable HTTP caching altogether, for example by setting `Cache-Control: no-cache, no-store, must-revalidate` on the response.
So, HTTP provides caching, but not the caching mechanism that's needed, so it's recommended to explicitly disable it completely.
With respect to status and error handling, it seems JMAP still had to define their own errors to be described in JSON[1], so not a perfect fit there either.
On the content encoding, I'm not sure if JMAP would use something other than application/json, so it seems like something that wouldn't need to be specified if one didn't use HTTP.
I know the discussion is not really about JMAP. I'm just using JMAP as an example on the above.
> TLS etc. (Simply, doing TLS correctly itself is not easy.)
I would hope that there's a library equivalent of the shell's:
openssl s_client -connect $host:$port
[1] https://jmap.io/spec-core.html#initial-jmap-error-codes-regi...