[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: sub-tree filtering proposals
At 12:09 AM 6/10/2004, Michael Walton wrote:
>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.
The code size at runtime, on the runtime platform, is the first
interesting number. The size of the compressed file on disk is
irrelevant. You don't show the most interesting number, which
is the static and dynamic data memory usage during the processing
of a <get-config> or <get> operation. Memory is a precious resource
on small embedded devices, which do networking as their primary task,
not Xpath. No customers are asking for Xpath on small devices --
there isn't enough config there to worry so much about retrieval filtering.
IMO, it is unacceptable to make Xpath mandatory because not all devices
need it nor can support it without impacting manufacturing cost.
>YMMV :-)
>
>Mike
Andy
>-----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/>
--
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/>