[jdev] Re: Net::Jabber::Protocol::CallBack() logic

[Scott Bolte]

	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
> reatmon at jabber.org
>