[SWMP] introducing RPC to an asynchronous protocol

["Jay C. Weber" <[e-mail]>]

[e-mail] wrote:

D)  I believe that swmp will need the full complement of CRUD (create, read, update, delete) operations.  I think the absence of read methods derived from the implicit subscription to all state.  Now, that one can subscribe to some, but not all of the state, I believe it will become desirable to request the values of unsubscribed state.  This prompted me to add a GETNODE and a GETFIELD request, which required GETNODEREPLY and GETFIELDREPLY messages to return the response.

Interesting, but the danger here is "return the response".  There's a big advantage to resisting the introduction of RPC-style elements in a context of minimizing latency -- obviously RPC involves a round-trip of messaging.  Keeping SWMP asynchronous will keep it mapping simply and efficiently onto datagram transports.

I like the PUB-SUB suggestions you've made, especially because PUB-SUB can be designed to work well in an asynchronous protocol.

jay

--
Jay C. Weber, Ph.D.
CTO, Media Machines Inc.
650-279-2311

_______________________________________________
SWMP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/swmp