RE: [SWMP] introducing RPC to an asynchronous protocol

["Tony Parisi" <[e-mail]>]

If we're talking about an either/or I prefer pub-sub to readback.

 

Tony

 

  _____  

From: Jay C. Weber [mailto:[e-mail]] 
Sent: Friday, August 24, 2007 9:04 AM
To: [e-mail]
Cc: [e-mail]
Subject: [SWMP] introducing RPC to an asynchronous protocol

 

[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