well, I'm thinking about two scenarios here.yeah, that was my thought. I started working on that but couldn't quite see all the pieces. here's what I have so far - it should compile cleanly and be good for a start, but it doesn't do anything (yet) due to the missing hooks.
But then you create a whole new filter, so whatever work is done in filter_init is lost. I guess you could still pass notes via the connection record. I thought that you want to create a filter early, run init on it and then use the same filter to do the real filtering.
the first is that a filter only needs filter_init to do some scut work - like update_mtime(), which is a required activity but does not need to be communicated _back_ to the filter that called the init. this is the type of thing that mod_include does (sets f->r->no_local_copy = 1) and that I was first interested in.
the other is when info _does_ need to come back to the calling filter, say via $filter->ctx or something.
the first could be handled with just a hook into filter_init - maybe by adding a whole new NULL filter with just the init (which probably won't work, but is worth a try), or adding a no-op filter. this would basically allow for anybody to add arbitrary code before request handlers run, which could be cool even outside of filters.
the second gets more complex - you need a way to associate the handler() routine with the init() routine in the handler so you can register the filter all at once. or maybe you don't if $filter->ctx is somehow magical, I dunno. all of this is requiring a pretty steep internals learning curve on my part :)
at any rate, my thought was to prototype the first part and save the second for later, after we get filter_init working in at least some fashion.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
