Re: Is DOM vs SAX a red herring?

[Larry Menten <lmenten@lucent.com>]

Karl,

If you use SAX, you are using much less memory and performing much less 
dynamic memory
allocation.  The result is a more compact, more robust, and faster 
implementation.

To my mind, the best approach to consistency checking is to place the 
responsibility within
the managed subsystem as John Moy does in his OSPF implementation.

We do the processing as follows:  As each start-element record is received,
parse the attributes of the element and validate the change in state of 
the element.
If it is desired to admit or fail the entire operation atomically, then 
put the updated values
into a pending state change structure within the target element.  Now, 
go on to process
all other requests in the transaction in the same way.  When the end of 
the transaction
is reached, perform a config-commit operation on each subsystem that was 
modified.

The pending state is resident in memory, but in binary form within the 
managed subsystems
and not has a large, dynamically allocated DOM tree.  Further, as 
validation checks take place,
in the managed sysystem, they are applied against previous updates from 
the transaction.

If you use SAX, you are using much less memory and performing much less 
dynamic memory
allocation.  The result is a more compact, more robust, and faster 
implementation.

Larry


Karl Auerbach wrote:

> I'm reading the discussion on XML attributes versus elements.  And much of 
> the argument seems to be on the relative memory and processing performance 
> of SAX versus DOM methods of decoding XML.
>
> (by-the-way, I'm leaning towards the "few attributes/more elements" side
> of the discussion.)
>
> > From my experience with doing SNMP set operations, the major job of the
> agent is to gather all the pieces of the proposed configuration change
> together and do a consistency analysis.  That kind of testing can easily
> be the largest part of the agent in a managed device.
>
> If one is doing that kind of evaluation of the proposed configuration data
> - and I suggest that any device that doesn't do it is taking quite a risk
> - then there will be a time when most of the proposed configuration data
> is going to have to be simultaneously resident in memory.
>
> It seems to me, therefore, that I am going to be paying the memory price
> of a DOM-like data tree even if I use SAX.
>
> 		--karl--
>
>
>
> --
> to unsubscribe send a message to xmlconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/xmlconf/>
>  
--
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/>