RE: sub-tree filtering proposals

["Michael Walton" <Michael.Walton@za.flextronics.com>]

Regarding code size of XPath: for interest and discussion's sake, I did a little footprint test using libxml2.

xpath.c seems to contain all the required processing, and is a fairly hefty source file at 324K.

Compiled and stripped it produces an object file of 88K. I tried gcc-i386 and gcc-ppc and both produce similar results.

Compressed (using mkcramfs for compressed ROM filesystem) it ends up at 36K. I haven't checked whether it incurs additional library requirements, etc. but I think it illustrates a point. 

YMMV :-)

Mike

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On Behalf Of Frank Strauß
Sent: Wednesday, June 09, 2004 10:35 PM
To: j.schoenwaelder@iu-bremen.de
Cc: netconf@ops.ietf.org
Subject: Re: sub-tree filtering proposals

On 09. Jun 2004, at 15:42, Juergen Schoenwaelder wrote:

> [...]
> First, I believe a subset of XPATH (not an adapted subset) is still 
> better
> than something homegrown.

I agree.

> (The most vocal members of the WG do not seem
> to buy full XPATH as a requirement.)

Maybe the reason is, that there are still not many operators and 
developers
of manager software raising their voice. (I'm just guessing.)

>  Personally, I believe that the
> operators using netconf will ask for full XPATH anyway, so the subset
> requirement will likely not be a real issue in practice.

However, a netconf standard should have the purpose to come to a common
sense on what agents support and what managers can rely on. If we have
reasons to assume that operators and others will ask for full XPath (and
I do think so, too) we should address this need *now* (and BTW not in a
subsequent revision as long as we did not even find rough consensus for
the initial revision).

> I think the general idea is that boxes announce whether they do 
> support full
> XPATH or just a reduced subset. I do not see that there is anything 
> wrong
> with this.

In general, I agree.

> The alternative, a home grow filter format which implementations are
> required to support, seems worse to me. Bottom line is that either
> (a) the netconf WG makes a decision to require XPATH full stop, or
> (b) the WG makes a decision to support XPATH and require a subset of 
> it, or
> (c) the WG makes a decision to support XPATH and to require another
>     home-grown filter format.
>
> Since (a) does not seem to be getting WG consensus, I believe (b) is 
> the
> best we can do.

First to say, my preference would be (a). If there are reasons against 
(a)
(I guess, I missed a discussion on this), I would also favor (b) over 
(c).


On 09. Jun 2004, at 18:22, Juergen Schoenwaelder wrote:

>> The advantages of the proposal above are:
>>   - subtree filtering is easy to implement on agents;
>>     only XML parser needed, not XML and Xpath parsers
>
> Come on, parsing Xpath expression is really not that complicated. I am
> really wondering on which basis you calculate how much you save on
> embedded boxes...

I would also like to see a clear reasoning, not just on the pure code
size. These aspects come to my mind:

- We should take into account that many XPath implementations exist.
   My expectation would be that deriving a subset implementation would
   need some time (not much, but more that just picking an existing
   full implementation) just to shrink the code size for a small
   percentage.
- An XPath subset would most probably *not* reduce CPU load compared
   to full XPath.
- Building a new XPath (subset) implementation from scratch could be
   required by some vendors' policies. A full implementation would fit
   in the idea of reusability, while a netconf subset would be limited
   netconf only.
- Same is true for a home-grown filtering mechanism.
- A less powerful filtering mechanism would cause more network traffic
   and thus increase network and CPU load, since managers would have
   to retrieve more data than required if the required filtering cannot
   be done on the agent side.

Furthermore, nowadays even the cheapest APs, switches and other devices
come with an HTTP server, SSH, SNMP, syslog, and much more stuff. 
Firmware
resides in relatively large, however cheap enough flash memory. The ease
of usability and manageability through such features often makes it an
attractive and successful product. This generally weighs more than the
costs to develop and build such features. At least, this is my 
impression.


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

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