2 ms·
Ah, see, I read the spec as saying that it would be things stored on the kitchen devices (toaster, etc). You do want to make sure your comms layer is easy to m
by pnathan 13y ago
Ah, see, I read the spec as saying that it would be things stored on the kitchen devices (toaster, etc).
You do want to make sure your comms layer is easy to make reliable when talking from the device, regardless. Might be HTTP, might not be - I'd likely take a gander at ProtoBuf myself for feeding over TCP/IP to minimize comms complexity on the phone home code.
- mwcampbell 13y agoI think I'd use HTTP as the synchronization protocol, because GET and PUT are specified as being idempotent, meaning it's safe to retry them. Also, HTTP is a ubiquitous standard, meaning there are several implementations to choose from, on both the client and server sides.
- pnathan 13y agoThe ubiquitous of HTTP is indeed a definite point in its favor(as is its popularity and level of documentation). > GET and PUT are specified as being idempotent, meaning it's safe to retry them. Entirely OT: Abstractly, yes, that's how they should be implemented, but they don't have to be and consequently it's entirely up to the receiving server whether they are or not. Which, in terms of assuming that someone will make unverified and bad assumptions, means that the implementer at some point will let them slip and become non-idempotent.