[sldev] Request For Comments: Patch to allow registering multiple message system handlers

[Dale Glass]

This adds new functions:
LLMessageSystem::addHandlerFunc: Adds a handler to the list of handlers 
LLMessageSystem::delHandlerFunc: Removes a previously added handler 
 
LLMessageSystem::setHandlerFunc is kept with its original functionality, 
removes all the registered functions, then adds the specified one. 
 

Intended usage:

LLFoo::LLFoo()
{
	LLMessageSystem *msg = gMessageSystem;
	msg->addHandlerFunc("FooMsg", fooHandler, NULL);
}

LLFoo::~LLFoo()
{
	LLMessageSystem *msg = gMessageSystem;
	if ( msg )
	{
		msg->delHandlerFunc("FooMsg", fooHandler);
	}
}

Users of this should check the existing handler before adding another and 
make sure that it won't get confused if it receives replies to requests 
made by some other part of the code.

This was made because my additions want to do the same things as existing 
parts of the code. For example the avatar list wants to parse the 
AvatarPropertiesReply message, which is also used by the profile screen.

It also makes patches somewhat cleaner, as by moving the required stuff to 
the new class' constructor it removes another potential source of a merge 
conflict.

IMO, the source should have more of this: Ideally I shouldn't have to be 
appending to files with long lists of various things that get initialized 
or registered. Ideally, a new screen should only need that the object gets 
constructed, and everything else should happen from the file that 
implements the new feature.


Soft commented that perhaps handlers should have a return value that 
indicates whether to continue executing the rest of the handlers. So far 
I've chosen not to do that because my code is written to be independent of 
anything else related going on, so if the profile screen happens to decide 
that it doesn't like what it got that doesn't mean my code wouldn't want 
it either.

Also changing the return type of all those functions would result in a huge 
patch. But this seems like something worth discussing: Do we need a system 
where the order in which handlers will be run can be defined, and where 
one of them can decide to stop the ones after it from running?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070921/993d82cf/attachment.pgp