A flag would be nice, but I don't think it would go far
enough. The issue that would be unresolved is the order in
which xpath callbacks are tested. Anyone using selective
callbacks would need the order to be deterministic.
It would be easy to modify the CB definition to control the
order. For example:
SetXPathCallBacks(xpath => function, ...)
SetXPathCallBacks(xpath => [order, function], ...)
Anything without an explicit order could have an implicit
order of zero.
The return value from a CB function would be 1 if it handled
the packet, and 0 if it didn't. Then iteration over the CB
funcs would stop once 1 was returned.
While I admit this may be feeping creaturism, I also see
it helping with defensive programming. When running in a
loosely defined environment this would make it easy to tell
when unexpected or malformed packets arrive.
Scott
On Thu, 08 Apr 2004 16:23:49 -0500, Ryan Eatmon wrote:
>
> Legacy. Really. I supposed I could put in flags to control that
> though. If you set the flag, then if there was an xpath match return,
> otherwise call the generic if it is defined.
>
>
> Scott Bolte wrote:
> > Ryan,
> >
> > The logic in the CallBack method for unregistered stanzas
> > is to first cycle through the XPath callbacks, and then,
> > inexorably, process generic tag (e.g. IQ) callbacks. Is
> > the unconditional use of the generic callbacks a deliberate
> > design decision or an artifact of the implementation?
> >
> > What I want to do is normally use XPath based callbacks for
> > messages. But if no XPath callback matches a new stanza,
> > then and only then have a generic 'default' callback invoked.
> >
> > I know I could maintain my own state table based on stream
> > ids, but that's a kludge at best. A more elegant approach
> > would be to use the return value of a callback to control
> > future processing of that stanza.
> >
> > Is such a change possible, or are there architectural
> > constraints?
> >
> > Scott
> >
>
> --
> Ryan Eatmon
> [EMAIL PROTECTED]
>
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
https://jabberstudio.org/mailman/listinfo/jdev
