[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Vincent Cridlig writes:
>I don't really understand the design choice of the get-syslog-streams
>operation because I think it breaks the idea of the get-config operation.
Syslog stream definitions are not limited to configuration, since
the device may define default streams.
>Wouldn't it be more conform to Netconf to define a short data model for
>syslog streams and use the regular get-config with a selection node ?
I'm not prepared to be the first lamb on that altar. ;^)
>For the second part 3.2, I am confused. What happens if I send a
>get-syslog-events with a stop-time one hour later ? Can I still use this
>Netconf session to send other RPC during this time ? I guess no. The
>Netconf session would be locked for a long period of time.
>If I understand well, this approach assumes that the agent is parsing
>the XML data stream on the fly (like with SAX, but not DOM). Because the
>rpc-reply does not seem to be closed until a stop condition happens and
>DOM can not read a partial document. If this is the case, must the agent
>assume that the rpc-reply message will be valid before it received the
>whole message ? And process it ?
Yes, if you are looking for a real-time stream, you'll need to
use a technology that allows you to parse it as it arrives. SAX
is perfect for this, giving you callbacks to drive a simple state
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.