[Opensim-dev] Event Queue

Stefan Andersson stefan at tribalmedia.se
Wed Dec 3 21:05:41 UTC 2008


EQ definitively should live in the Client Stack. +1 from me if anybody wants to have a look at it.Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ > From: adam at deepthink.com.au> To: opensim-dev at lists.berlios.de> Date: Wed, 3 Dec 2008 12:49:25 -0500> Subject: Re: [Opensim-dev] Event Queue> > I've suggested on a few occasions to move it into ClientStack - that's where this belongs.> > EventQueue messages should be sent/received the exact same way that UDP ones are.> > SendXYZMessage() on ClientStack, and OnXYZRecieved events also on clientstack.> > Adam> > > -----Original Message-----> > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-> > bounces at lists.berlios.de] On Behalf Of Cristina Videira Lopes> > Sent: Wednesday, 3 December 2008 9:40 AM> > To: opensim-dev at lists.berlios.de> > Subject: [Opensim-dev] Event Queue> >> > Apologies in advance for bringing up everyone's favorite hate topic,> > but> > having spent most of yesterday tracking TP/crossing problems (again), I> > can't help but bringing this up to a wider audience. I know everyone> > hates the EQ. As it stands, there are several broken elements with the> > EQ in OpenSim, beyond the obvious bugs caused by its management. I'm> > just wondering if there is something here that I'm completely missing,> > or if this is really this bad:> >> > 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.> >> > 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.> > 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. After all, it's the new channel of communications> > between a server and the LL viewer. Things that used to go over UDP are> > now sent via the EQ, period, no choice. Region Environment should be> > completely oblivious to that change. As it is now, this pattern occurs> > all over Region Environment classes:> >> > IEventQueue eq => > [scene.]RequestModuleInterface<IEventQueue>();> > if (eq != null)> > {> > // send the event over EQ> > }> > else> > {> > // call the right IClientAPI method to send the event> > [over UDP]> > }> >> > This is infecting the server side with things that should be purely> > client side. It's a horrendous way of getting at the question "what> > version of the LL viewer are you supporting in your region?". If there> > is such a thing as a wrong question to ask, this is one of them. If we> > want to support viewers with older communication stacks, 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. No OpenSim.ini> > configuration variables, other than the already existing one:> > clientstack_plugin="OpenSim.Region.ClientStack.LindenUDP.dll"> >> > What will happen when Rex comes along? ... what version of the LL> > viewer> > is that based on? ...> >> > Sorry for venting! I'm just sending this out to find the answer to> > these> > three questions:> >> > a) Am I missing something?> >> > b) Are there any objections to placing EQ under> > OpenSim.Region.ClientStack.LindenUDP? (besides that name now being> > somewhat incorrect)> >> > 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?> >> > _______________________________________________> > Opensim-dev mailing list> > Opensim-dev at lists.berlios.de> > https://lists.berlios.de/mailman/listinfo/opensim-dev> _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081203/630f78ee/attachment-0001.html>


More information about the Opensim-dev mailing list