[Opensim-dev] Event Queue

[Stefan Andersson]

Cristina,
 
> Apologies in advance for bringing up everyone's favorite hate topic, 
 
Thank you for doing so.
 
> I'm > just wondering if there is something here that I'm completely missing, > or if this is really this bad:
You're not, it is - the EQ was and still is, i guess, a panicked hack introduced just to maintain the least slice of viewer compatibility.
 
You're right - we hate it, and fear to thread near it.
> 1) It's implemented as an optional region module (!!!), configurable in > OpenSim.ini (!!!). That explains why, for example, I could not reproduce > crashes that other people have reported with older viewers. It turns out > that those people are not just using older viewers; they are using > OpenSim servers configured with EventQueue=false. A complete > miscommunication.
Yes, at one point in history, we didn't relly know much about the EQ or what role it would play - and separating this beast that didn't do much out into a module made sense then. Now, we know better - it should be part of the Linden specific Client Stack.
> 2) It's implemented as an optional region module -- the sequel. It is > being considered a [optional] part of the Region Environment, something > a region may or may not do. I'm afraid, this is the incorrect model. 
 
In deed.
 
>The > server side doesn't have any choice on this, if it wants to interact > with the current version of the LL viewer. The EQ should be hand-in-hand > with LLClientView. 
 
So true. I love you for saying so.
 
> After all, it's the new channel of communications > between a server and the LL viewer.
 
Last I heard, LL have been very flaky on what to use EQ for, and what not to - has that changed? Is there a clear map over what is EQ-mandatory vs UDP-mandatory today?
 
> Things that used to go over UDP are > now sent via the EQ, period, no choice.
 
Historically, packets seem to have been transferred from UDP to EQ on a per-packet, day of week and influenced by sunspot activity base.
 
> If we > want to support viewers with older communication stacks,
 
Do we?
 
> then let's make > that explicit in OpenSim and subclass LLClientView for the N previous > versions of the LL viewer's communications stack. Region Environment, > and the whole of the OpenSim framework, should be insulated from that > mess, that's what the IClientAPI is there for.
 
With that I do agree.
 
> No OpenSim.ini > configuration variables, other than the already existing one:> clientstack_plugin="OpenSim.Region.ClientStack.LindenUDP.dll"
+1
> What will happen when Rex comes along? ... what version of the LL viewer > is that based on? ...
The about in 0.4 says it is based on KirstenLee 1.15.
> Sorry for venting! 
 
Perfectly understandably. The rest of us vented half a year ago or so.
 
> I'm just sending this out to find the answer to these > three questions:> > a) Am I missing something?
Nope, you're probably perfectly right.
> b) Are there any objections to placing EQ under > OpenSim.Region.ClientStack.LindenUDP? (besides that name now being > somewhat incorrect)
I haven't seen nobody not +1'ing that. Change the name as well.
> c) Should OpenSim be backwards compatible with viewers forked off from > older LL viewers *for the specific aspect of communications*? If so, > what design pattern should be used?, subclassing or alternative code > paths inside methods?
That I leave up for discussion, but I believe that doing so can get very messy fast.
 
But, I think Adam et al has proposed a re-engineering of the client stack that will probably help - by letting each client implement several interfaces, instead of just one.
 
/Stefan
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081205/8e07ced4/attachment-0001.html>