Re: Is DOM vs SAX a red herring?

[Andy Bierman <abierman@cisco.com>]

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 


--
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/>