tag:blogger.com,1999:blog-3454984.post991616433960046715..comments2023-07-15T03:39:20.802-07:00Comments on Not Invented Here: Unknownnoreply@blogger.comBlogger3125tag:blogger.com,1999:blog-3454984.post-92194715004405123902010-04-09T11:52:16.404-07:002010-04-09T11:52:16.404-07:00I think the rigid client-server, request-response ...I think the rigid client-server, request-response nature of HTTP is also a large problem. A simple peer-to-peer protocol allowing unsolicited msgs from either side would be better. Or at least a subscribe model. Its very hard to use HTTP to request for asynchronous updates, AJAX style webapps jump through enormous hoops to deal with this limitation, and semi-autonomous loosely connected wireless devices are going to find it even worse. I've never understood why we can't just use a (possibly chopped down) zigbee stack.samhttps://www.blogger.com/profile/07253677361533166582noreply@blogger.comtag:blogger.com,1999:blog-3454984.post-79826173375436493882010-04-07T01:36:16.147-07:002010-04-07T01:36:16.147-07:00Are today's devices really that limited? I bel...Are today's devices really that limited? I believe the value in terms of developer friendliness vastly outweighs the resource cost, though it does make sense for such interfaces to constrict HTTP to the bare minimum (for example by enumerating valid HTTP status codes and what they mean in context). If you're worried about overhead then SPDY is one option - and certainly a better one than rolling your own protocols or using something relatively difficult to work with like SNMP.Samhttps://www.blogger.com/profile/10615456356100777841noreply@blogger.comtag:blogger.com,1999:blog-3454984.post-86955400153067908892010-04-06T16:04:03.178-07:002010-04-06T16:04:03.178-07:00I agree that HTTP as-is may not be appropriate for...I agree that HTTP as-is may not be appropriate for limited devices (although it's interesting to observe the mobile world, where just a few years ago HTTP+HTML was judged inappropriate; look at us now!).<br /><br />However, I'm wary of limiting its semantics. E.g., you say 504 isn't useful; however, lots of my automated agents send Cache-Control: only-if-cached, where a 504 response means that the requested representation isn't in cache, allowing them to do a cheap lookup easily.<br /><br />I think a better approach -- if you want to base this on HTTP -- would be to maintain fidelity to HTTP's semantics, while making its serialisation more efficient. The SPDY experiment by Google is showing some promise in this regard; compare the complexity of a HTTP parser vs. a SPDY parser by comparing http_common and spdy_common in <a href="http://github.com/mnot/nbhttp/tree/spdy/src/" rel="nofollow">nbhttp</a>. <br /><br />BTW, IME clients implementations -- especially full-featured ones -- are much tricker and more complex than servers. YMMV, of course.Mark Nottinghamhttp://www.mnot.net/noreply@blogger.com