[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Netconf! Part Deux
"Randy Presuhn" writes:
>Seriously, I think this shows how what makes sense for incremental
>editing of (the representation of) a configuration isn't necessarily
>going to be very pretty for shoveling it around en masse or vice versa.
I'm not sure I buy that. The expense in that example was two copies
of the hierarchy to frob one knob. Normal use cases aren't so different:
[edit]
root@hang# show | count
Count: 116 lines
[edit]
root@hang# show | display xml | count
Count: 170 lines
[edit]
root@hang# show routing-options
static {
route 0.0.0.0/0 {
next-hop 152.14.12.49;
retain;
no-readvertise;
}
}
[edit]
root@hang# show routing-options | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/6.1B1/junos">
<configuration>
<routing-options>
<static>
<route>
<name>0.0.0.0/0</name>
<next-hop>152.14.12.49</next-hop>
<retain/>
<no-readvertise/>
</route>
</static>
</routing-options>
</configuration>
</rpc-reply>
[edit]
root@hang#
'show routing-options' skips the 'routing-options' statement, but
you can see the parallels.
Most of the 116 .vs. 170 difference is the way we try to save screen
space for the human user where we don't condense anything in xml.
>It's a good reality check for those of us who heard the operators
>saying that they wanted the CLI and protocol to be identical.
The needs of humans and the needs of machines are very different.
Line counts and brevity mean nothing to your java app.
Thanks,
Phil
--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>