[Opensim-dev] [Opensim-commits] r8496 - in trunk/OpenSim/Region: CoreModules/Avatar/InstantMessage Framework/Interfaces

[Melanie]

I see an issue there.

Currently we use simple events. AN event calls all it's handlers in 
no particular order, and if the handler is defined as having a 
return value, the value returned from the event invocation is the 
return value of the last handler, whichever that happened to be.
There are no guarantees as to which handler runs first, although I 
know that both current implementations call the handler in the order 
they were registered. This behavior can not be depended upon.

So, to make this work with return values, it would require a huge 
code mess (like Scene.Permissions), with a boatload of code written 
for each event, or, if it's done through generics or dictionaries, a 
severe performance hit.

Therefore, despite my prior +1 to the concept as such, it's not 
doable in that way. There has to be a way, there always is. It just 
needs to be found.

I think it could be done by creating a new class, ModuleEvent<T>. T 
would be the delegate type, so you would instantiate the class in 
EventManager like so:

public delegate bool DoSomethingDelegate(whatever parms);

public static ModuleEvent<DoSomethingDelegate> DoSomething;

and used like so:

DoSomething.AddHandler(T);
DoSomething.RemoveHandler(T);

DoSomething.Handler(whatever parms);

where Handler is public T Handler {get;}

Would that be feasible?

The point is to reduce implementing a new event to adding 2 lines, 
rather than 20.

This intrigues me, I'm going to try that :)

Melanie


Justin Clark-Casey wrote:
> mw at opensimulator.org wrote:
>> Author: mw
>> Date: 2009-02-19 04:38:17 -0800 (Thu, 19 Feb 2009)
>> New Revision: 8496
>> 
>> Modified:
>>    trunk/OpenSim/Region/CoreModules/Avatar/InstantMessage/MessageTransferModule.cs
>>    trunk/OpenSim/Region/Framework/Interfaces/IMessageTransferModule.cs
>> Log:
>> reverted last revision, until we decide how to handle capturing IM's
> 
> mw, was this in support of the jabber/xmpp bridge that you've coded?
> 
> If so, I encountered a similar problem while doing the parallel selves message bridge.  My 'solution' was to entirely 
> replace the MessageTransfer (and chat) modules, which is just nasty.
> 
> My thoughts for a long term solution were to
> 
> a) Make some event calls such as those on EventManager.OnIncomingInstantMessage require a boolean to be returned by each 
> call (which I believe is possible in c#).  This boolean would signal that the message has already been completely 
> handled, and that it shouldn't be passed on to other modules.
> 
> b) Define an 'order' in which modules are loaded in some config file.
> 
> With these two things, an xmpp bridge module could be loaded before the 'ordinary' im module.  If it gets an incoming im 
> which it can handle, then it handles it and returns true (to signal that it shouldn't be passed on to any other module). 
>   If it can't handle it then it simply returns false and the message goes through to the next module on the list (in 
> this case, the 'ordinary' module).
> 
> I like this solution because I think that it allows composibility - you can load lots of different 
> OnIncomingInstantMessage handling modules without any of them having to be aware of any other.
> 
> What do you (or others) think?  Are there better approaches?
>