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

[Justin Clark-Casey]

Melanie wrote:
> 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.

Ah good point.  I didn't realize that preserving registration order as call order wasn't part of the standard.

> 
> 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 :)

Sounds like a good thing to explore :)

> 
> 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?
>>
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com