On Thu, 2005-08-25 at 00:07 +0200, Anthony Novatsis wrote:
> I am not sure what initalisation code that you are referring to?
The code where you first register the table, and set up the
cache handler. I'd expect this to look something like:
init_myTable() {
reg = netsnmp_create_ha
On Thu, 2005-08-18 at 20:06 +0200, Anthony Novatsis wrote:
> I know it is possible to use the cache and the table iterator
> handlers. However, I would like to know whether it is possible to
> retrieve the netsnmp_cache structure within the get_first_data_point
> function (without the use of a glo
On Fri, 02 Jul 2004 09:49:46 +0100 Dave wrote:
DS> RS> What you've proposed is pretty much the way it works now, except
DS> RS> the default for the flag is no auto next.
DS>
DS> Except that I'm suggesting that we have a quick push to convert
DS> *all* the (internal) helpers as far as possible (and
DS> - By default, handlers return success/failure, but don't explicitly
DS> call the next handler in the chain. This is (normally)
DS> done by the main netsnmp_call_next_handler routine.
DS> (i.e. AUTO_NEXT becomes the default)
RS> Well, the problem ther
On Thu, 01 Jul 2004 11:15:10 -0700 Wes wrote:
WH> > On Thu, 1 Jul 2004 13:39:46 -0400, Robert Story (Coders)
WH> DS> - By default, handlers return success/failure, but don't explicitly
WH> DS> call the next handler in the chain. [...]
WH>
WH> Robert> Well, the problem there is that it's not
> On Thu, 1 Jul 2004 13:39:46 -0400, Robert Story (Coders) <[EMAIL PROTECTED]>
> said:
DS> Ok - maybe an example would help.[...]
DS>
DS> Robert> Some of the helper handlers, however, do care. Again, bulk_to_next
DS> is the best example. It needs to do something before and after [...
On Thu, 01 Jul 2004 12:41:19 +0100 Dave wrote:
DS> Robert> I don't think what I'm proposing takes away any flexibility.
DS>
DS> Ok - maybe an example would help.[...]
DS>
DS> Robert> Some of the helper handlers, however, do care. Again, bulk_to_next
DS> is the best example. It needs to do som
On Wed, 30 Jun 2004 15:20:06 -0700 Wes wrote:
WH> > On Wed, 30 Jun 2004 13:08:25 -0400, Robert Story (Coders)
WH> 2) However, Robert is wrong that it helps APIs.
Thems theres fightin' words. I would understand 'I disagree', but 'wrong'
seems a bit strong.
WH>Since we can not and
WH>s
On Thu, 01 Jul 2004 11:34:28 +0100 Dave wrote:
DS> DS> Thinking about this in abstract, it would probably be sensible for
DS> DS> a lower-level handler to be able to retrieve *either* of these
DS> DS> netsnmp_extract_cache_info(netsnmp_agent_request_info * reqinfo)
DS> DS> netsnmp_extract
DS> I think the pipeline has some advantages - it's somewhat more flexible
DS> in terms of exactly when and where the next handler is called,
DS> and what (if anything) is done afterwards.
Robert> I don't think what I'm proposing takes away any flexibility.
Ok - maybe an example would help.
Suppo
DS> The cache itself isn't
DS> normally available explicitly, except by re-casting the 'magic' pointer
DS> (which feels as if it ought to be private to the handler internals).
Robert> By 'magic' you mean 'myvoid', right?
Err... yes, probably.
> On Wed, 30 Jun 2004 13:08:25 -0400, Robert Story (Coders) <[EMAIL PROTECTED]>
> said:
DS> Robert> it stands at 2-1.
DS>
DS> Yes - I'm getting used to that :-(
Robert> Well, we've all been there. You just need to come work for us,
Robert> and then together we can rule the world! Mwuuuh
On Wed, 30 Jun 2004 15:52:23 +0100 Dave wrote:
DS> Having a set of handlers called "in sequence" is a perfectly reasonable
DS> alternative model. I'm unconvinced as to whether it's necessarily
DS> better than the current "pipeline" model, but it's certainly not a
DS> poor choice.
I'm not sure I
On Wed, 30 Jun 2004 15:52:20 +0100 Dave wrote:
DS> Robert> Well, technically, the handler had to have requested the cache in
DS> Robert> the first place, so it could have save the cache pointer when it
DS> Robert> created it
DS>
DS> Sort of.
DS> The lower level code typically creates a normal hand
DS> But the only reason that the cache needed to be linked with the reqinfo
DS> parameter was that this was the only way that lower handlers could get
DS> hold of it.
Robert> Well, technically, the handler had to have requested the cache in
Robert> the first place, so it could have save the cac
Robert> Replace 'eliminating the redundant loop' with 'eliminating an
Robert> unnecessary function call and reducing the stack depth.' (Have you
Robert> looked at a back trace from a low level handler? It's horrendous.)
No argument there!
Robert> I think that it's that it's a change from how
On Tue, 29 Jun 2004 09:30:45 +0100 Dave wrote:
DS> Robert> A while ago I added a 'flags' field to the mib handler structure.
DS> Robert> One of the flags avaiable is 'AUTO_NEXT', which if set, will call
DS> Robert> the next handler automatically. Seemed this behaviour belonged at
DS> Robert> a high
On Tue, 29 Jun 2004 10:29:54 +0100 Dave wrote:
DS> Robert> The original idea was to fetch the
DS> Robert> cache from the reqinfo first thing
DS> Robert> . This was an extension of your work...
DS> Robert> I just extended the concept into
DS> The most recent change now uses what appears to be a
DS> completely separate cache structure, extracted from an
DS> internal list.
Robert> The original idea was to fetch the
Robert> cache from the reqinfo first thing
Robert> . Thi
Dave> But now the handler seems to return success or failure immediately,
Dave> without actually calling any lower-level handlers.
Dave> This seems to be at odds with my understanding of the handler design.
Robert> A while ago I added a 'flags' field to the mib handler structure.
Robert> One of
On Mon, 28 Jun 2004 14:21:11 +0100 Dave wrote:
DS> Firstly, there appears to be an inconsistency in the
DS> way that the cache is referenced
You are right, it should be consistent. I'll get that fixed today.
DS> The most recent change now uses what appears to be a
DS> completely separate cache
On Mon, 28 Jun 2004 14:21:11 +0100 Dave wrote:
DS> The second issue relates to the overall form of the handler routine.
DS> The general model of the v5 handler chain architecture is of a series
DS> of routines, each of which takes care of certain aspects of the request
DS> and then passes control
22 matches
Mail list logo
