Larry,
Your latest example (included below) seems different than your first proposal.
<addRequest opId="3"
select="/root/configuration/protocol/ospf"> ... </area> </addRequest> is different from:
<area id="4" op="addRequest"> ... </area>
I thought something along the lines of the latter was what you were proposing. Sorry if I misunderstood.
Just to make sure I understand this message, your example would: Delete OSPF area 0 Delete OSPF area 3 Add a new OSPF area 4 with one interface (ge-2/2) in it Modify interface ge-1/5 in OSPF area 2 to have a dead interval of 40 Add a new IS-IS area 5 Add an LSP named "to-SFO" to OSPF area 1 with a metric of 15 Change the metric of the LSP named "to-SFO" in OSPF area 6 to 20
All as a single atomic transaction.
Your use of X-Path is intriguing. I think the conventional wisdom has been that X-Path would be too complicated to implement on an embedded system. It is cleaner, though, than the approach this group has been pursuing, which would be to include the parent elements in the XML payload. Have you been able to implement X-Path on a small embedded system?
Are there semantics associated with the opID attributes in your example? Since it seems to be an atomic transaction I assume they do not imply order of execution. Why are they needed? Same with the transaction IDs.
Keith Allen SBC Technology Resources 9505 Arboretum Blvd. Austin, TX 78759 (512) 372-5741
-----Original Message-----
Keith, |