Open bradrydzewski opened 8 years ago
If a device is powerful enough (CPU/memory) to handle TCP+HTTP (for websockets), why would it need CoAP? I thought that CoAP was intended for those constrained devices that don't want to handle TCP state and HTTP parsing.
Some devices have battery life restrictions, so web sockets will not work well.
I think the draft rfc describes some interesting use cases for websockets http://www.ietf.org/id/draft-savolainen-core-coap-websockets-05.txt but implementing such a feature in this library would largely depend on that draft being accepted and the author of this library being interested.
Some devices have battery life restrictions, so web sockets will not work well.
I'm not suggesting this be the default implementation. I do think go provides some nice interfaces with io.Reader
and io.Writer
that might allow the underlying transport to be separated from the implementation. This is something you see in the underlying Go rpc package which support rpc.NewClient(conn io.ReadWriteCloser) *Client
But again, just a suggestion and the owner can feel free to close if this is out of scope for the library, or if the draft spec for websockets has been rejected.
Not sure this is in-scope for what you're doing, but looks like there is draft support for websockets as a protocol which seems really interesting http://www.ietf.org/id/draft-savolainen-core-coap-websockets-05.txt