[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is DOM vs SAX a red herring?



Karl Auerbach wrote:
On Mon, 12 May 2003, Larry Menten wrote:

  
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
asn John Moy does in his OSPF implementation.
    

I have found that any responsible agent (please excuse me for using 
the obsolute snmp word "agent" - I find it to be fairly descriptive) to 
take care about consistency above and beyond the tests by any individual 
subsystem of the configured-device.
  
An example I used in the past is that of a submarine being configured.  
Somewhere there needs to be a cross check between the "submerge"  
configuration option and the "screen door closed and locked" option.

Now, in any good device the "submerge" button checks that the doors are 
closed.  But we know how real devices are. ;-)  And I don't want my 
configuration agent to sink my device.
In the past, creating such a "responsible agent" required artificially
structuring the MIB so that the variables that needed to be consistent
were in the same MIB group. You will notice that even in this advanced
age, we are proposing that the ability to validate before setting be made
optional.  I have plenty of hands-on experience with market leading routing
products.  The management code in these products would not qualify for
"responsible agent."   This also includes third-party SNMP packages.

Instead, folks structure the MIB to localize these consistency
requirements.
 



  
This raises the issue of the ordering sequence of configuration commands 
in a single transaction - if a single transaction says 'close screen 
doors' then can the 'submerge' button be pressed in that same transaction 
if it occurs later in the list of things to be configured in the 
transaction?

  

  

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

  

  

This is how many snmp agents did it.  A problem arose when there were
multiple configuration settings for the same thing.  One then has to say
whether the underlying item is idempotent or whether the configuration
actions are merged into a single configuration action taking as its value 
either the first or the last (or the average? ;-) of the settings that are 
being attempted.
  





We use the last setting.  XML allows flexible expression of network

management operations.  You have a choice.  Dumb it down or accept the

consequences of the expressiveness and power.  I vote for expressiveness

and power.




  
  

  

    
The pending state is resident in memory, but in binary form within the
managed subsystems and not has a large, dynamically allocated DOM tree.
    

  

  

Much agreed that it is not as large.  My original point is that the
apparent savings from SAX may not be as large as one might initially think
because of the need to sometime, somewhere of putting all the proposed
configuration into memory at the same time and programatically staring at
it to see if it is consistent.
  





The apparent savings from SAX is every bit as large as one might
initially

think.



The semantics of validate before set require that the current and
proposed value

be retained until the validate operation is to be performed.  That is
unavoidable.

But would you rather save a 32-bit value (four bytes) that does not
require a

dynamic memory allocation or woudl you prefer to create and retain
retain four

hundred or more dynamically allocated bytes of a DOM tree
representation, complete

with namespace references, etc. that expresses the same thing? 




  
It would be nice if parts of the configuration data could be formally 
defined as having no side effects on other parts so that one need only 
bring in certains subtrees of the total proposed configuration data.

		--karl--
  





  


  



Larry


-- 
Larry Menten               Lucent Technologies/Bell Laboratories
Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA