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:
>> m...@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@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
--
justincc
Justin Clark-Casey
http://justincc.wordpress.com
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
