[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Separation of configuration and control - good or bad?
In the below... I'm confused. Why would I need two parsers?
Also, I'm concerned that it's starting to look like that
if I have a device that has "config X", and I reboot the
device and I want it to come back up in "config X", then
there maybe a combinations of config and control operations
that have to be applied.
One final comment... I believe that providing the capability
for authorization is another factor that is going to affect
the look and feel of the protocol.
At 03:18 PM 5/15/2003 -0400, Larry Menten wrote:
>If control operations (clear LSDB,...) are separated
>from configuration operations (change retransmit-interval),
>then two different kinds of transaction must be expressed.
>This will require twice as much text to represent the transaction
>since the subtree must be duplicated.
>The configuration operations will be parsed by code that
>interprets configuration operations, control operations will
>be processed by code that can interpret control operations.
>This is necessary because the config operations create a persistent
>config state file while the control operations are not retained in
>There is more text to exchange in the transaction, more text to parse,
>and two different parsers to implement. Assume that the purpose of the
>control operation is closely related to the config operation. The two
>closely related operations are now in separate XML trees in the transaction
>and it is now less obvious upon reading the transaction that the two operations
>are closely related.
>Furthermore, the management code must accommodate a different syntax for these
>control command. More code.
/david t. perkins
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.