<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Cristina,<BR>
<BR>
> Apologies in advance for bringing up everyone's favorite hate topic, <BR>
<BR>
Thank you for doing so.<BR>
<BR>
> I'm <BR>> just wondering if there is something here that I'm completely missing, <BR>> or if this is really this bad:<BR><BR>
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.<BR>
<BR>
You're right - we hate it, and fear to thread near it.<BR>
<BR>> 1) It's implemented as an optional region module (!!!), configurable in <BR>> OpenSim.ini (!!!). That explains why, for example, I could not reproduce <BR>> crashes that other people have reported with older viewers. It turns out <BR>> that those people are not just using older viewers; they are using <BR>> OpenSim servers configured with EventQueue=false. A complete <BR>> miscommunication.<BR><BR>
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.<BR>
<BR>> 2) It's implemented as an optional region module -- the sequel. It is <BR>> being considered a [optional] part of the Region Environment, something <BR>> a region may or may not do. I'm afraid, this is the incorrect model. <BR>
<BR>
In deed.<BR>
<BR>
>The <BR>> server side doesn't have any choice on this, if it wants to interact <BR>> with the current version of the LL viewer. The EQ should be hand-in-hand <BR>> with LLClientView. <BR>
<BR>
So true. I love you for saying so.<BR>
<BR>
> After all, it's the new channel of communications <BR>> between a server and the LL viewer.<BR>
<BR>
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?<BR>
<BR>
> Things that used to go over UDP are <BR>> now sent via the EQ, period, no choice.<BR>
<BR>
Historically, packets seem to have been transferred from UDP to EQ on a per-packet, day of week and influenced by sunspot activity base.<BR>
<BR>
> If we <BR>> want to support viewers with older communication stacks,<BR>
<BR>
Do we?<BR>
<BR>
> then let's make <BR>> that explicit in OpenSim and subclass LLClientView for the N previous <BR>> versions of the LL viewer's communications stack. Region Environment, <BR>> and the whole of the OpenSim framework, should be insulated from that <BR>> mess, that's what the IClientAPI is there for.<BR>
<BR>
With that I do agree.<BR>
<BR>
> No OpenSim.ini <BR>> configuration variables, other than the already existing one:<BR>> clientstack_plugin="OpenSim.Region.ClientStack.LindenUDP.dll"<BR><BR>
+1<BR>
<BR>> What will happen when Rex comes along? ... what version of the LL viewer <BR>> is that based on? ...<BR><BR>
The about in 0.4 says it is based on KirstenLee 1.15.<BR>
<BR>> Sorry for venting! <BR>
<BR>
Perfectly understandably. The rest of us vented half a year ago or so.<BR>
<BR>
> I'm just sending this out to find the answer to these <BR>> three questions:<BR>> <BR>> a) Am I missing something?<BR><BR>
Nope, you're probably perfectly right.<BR>
<BR>> b) Are there any objections to placing EQ under <BR>> OpenSim.Region.ClientStack.LindenUDP? (besides that name now being <BR>> somewhat incorrect)<BR><BR>
I haven't seen nobody not +1'ing that. Change the name as well.<BR>
<BR>> c) Should OpenSim be backwards compatible with viewers forked off from <BR>> older LL viewers *for the specific aspect of communications*? If so, <BR>> what design pattern should be used?, subclassing or alternative code <BR>> paths inside methods?<BR><BR>
That I leave up for discussion, but I believe that doing so can get very messy fast.<BR>
<BR>
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.<BR>
<BR>
/Stefan<BR>
<BR></body>
</html>