At 12:00 PM 5/13/2003, Larry Menten wrote:
Phil,
Rob,
I'd like to propose that we compare the representational approaches
for paracticality for small systems by taking a realistic example and
characterizing what is required to process it. Including:
How validation is accomplished (validating parser required?).
How much custom code must be created for the elements of the example.
What level of XML library support is required.
What use is made of dynamically allocated memory.
I propose that we use the creation of an MD5 authentication key on an
ospf interface as an example.
Are you interested?
Although these DOM vs. SAX implementation comparisons are interesting
at some level, we need to be careful about making high-level protocol
design choices based on DOM vs. SAX, etc., especially on embedded
systems. Vendors may make any number of design choices to implement
SW which conforms to this standard, and we should not make too many
assumptions about those choices. If there is an order of magnitude
difference in memory or CPU requirements, that would be interesting,
but I don't think that's the case here.
I am also very wary of lumping all devices together in a quest
for the Grand Unified Theory of NM Protocols. Obviously, a
core router with 100s or 1000s of interfaces is going to have
way more resources than some tiny end-user device. The protocol
should not be crippled (from the core router POV) because there
might be small devices which are resource-constrained. The
NETCONF protocol should be implementable on both types of devices --
the size of the config data is the limiting factor, not the protocol
operations themselves. (The protocol needs a TOO_BIG error like
SNMP has.)
Larry
Andy
Phil Shafer wrote:
Larry Menten writes:
But the use of elements does require that the parsed elements be cached until enough
information has been collected to parse them. Except for trivial examples, this means that
you will be allocating memory dynamically to store these until you have collected enough
elements to identify and configure the target object.
...
You have provided just the leaf. With JUNOS you must retain the entire
tree in memory:
...
I am storing just the name, namespace ID, and attribute list for one
single element.
Given that the data is hierarchical in nature, how does using
attributes relieve you from tracking where you are in the configuration
hierarchy? You've got to know the parent hierarchy for your particular
element, so you need to track the same information. Attributes may
change the form of the data, but not what you need to do with it.
SAX may give you a complete set of attributes at once, but it will
normally allocate memory for these strings before handing them to
your code. I'm not following the element-implies-dom-implies-big
progression, mostly 'cause we use element, don't use DOM, and have
a fairly small footprint.
Thanks,
Phil
--
to unsubscribe send a message to <mailto:netconf-request@ops.ietf.org>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/>
--
Larry Menten Lucent Technologies/Bell Laboratories
Phone: 908 582-4467 600 Mountain Avenue, Murray Hill, NJ 07974 USA