[Opensim-dev] Upcoming work on alternative client stack

[Melanie]

Hi,

I have done much work on moving lower level packet handling stuff into 
the separate LLPacketHandler class. There is very little actual 
transport handling left in LLClientView, and what is left in there now 
is also on the way out, as I am going to make the PacketHandler class 
handle the connection as well.

I Think those are steps in the right direction, and I fully agree that 
we need to remove the remaining knowledge of Packets from the core. But 
simply changing them to Byte[] and then claiming to be packet-free is 
not a solution.

Also, we all agree the LL protocol is terminally broken. I hate to see 
the waste of time & effort going into creating a new, totally separate 
stack to implement the same broken protocol again.
Wouldn't we be better off defining a new protocol and working with 
people building alternative viewers to get this implemented across the 
board?

Melanie


Stefan Andersson wrote:
> Just a couple of quick points, what with being one of the guardians of the architectural spirit;
>  
> * First of all, can the whole InPacket() construct in client manager be refactored so that the specific type knowledge moves into the client stack? One could argue that those parts of the client manager that uses fields like 'circuit code' and 'packet' should be in a LLClientManager that keeps track of all LL-compatible clients. You probably would want an RexClientManager that handled Rex clients; the 'ClientManager' would then keep track of all 'local' clientmanagers, in an protocol-agnostic way.
>  
> I believe we need this, as it seems we're nearing a situation where we have three-four, maybe five different client stacks coming up. (And only god knows how many separately developed - I would love to see a minimal Xenki-optimized stack)
>  
> * Passing objects around and recasting them is generally an indication of needing to re-think things.
>  
> * This work that's done on implementing a non-libsl stack is great, optimized or not, as well as the work done with implementing a rex-stack - this is a great driver and the real pudding-proof of our long-term goals of being able to serve various clients. (Even if these are all LL variations, it's a big first step)
>  
> I don't think we need to do this work in a separate branch to prove it - I think we should just do it; retain the orginal stack, let people switch preferred stack and see what works best.
>  
> The challenge is to refactor the comms code so we can use separate stacks for separate clients - something I've been longing for for a long time to happpen. :D
> Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 
> 
> 
> 
>> Date: Mon, 18 Aug 2008 09:08:43 +0900> From: mmazur at gmail.com> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] Upcoming work on alternative client stack> > Hi Adam,> > On Sun, 17 Aug 2008 14:27:12 -0400> "Frisby, Adam" <adam at deepthink.com.au> wrote:> > > Please be careful here.> > > > I'm doing some work with the RealXtend guys to move their custom code> > into a set of Region Modules, however I need the SendPacket(Packet x)> > function on IClientAPI to do so.> > > > Now admittedly there's only a few custom packets, and we could extend> > IClientAPI to support them - these are:> > > > 1. GenericMessagePacket - Rex has moved to using these to> > overload all their messages onto (so that the existing client ignores> > them safely), we don't have a IClientAPI.SendGenericMessage(string[]> > msg) equivalent yet. This could be one way we get around this.> > > > 2. Convert to SendPacket(Byte[] x), then run> > GenericMessagePacket.ToBytes() before passing it to IClien
tAPI?> > I'm not sure I fully understand the issue.> > My changes in IClientAPI is to replace Packet with object:> > IClientAPI:> - void InPacket(Packet NewPack);> + void InPacket(object NewPack);> > This way the interface doesn't dictate the datatype of the packet, but> the implementing class does:> > LLClientView (implements IClientAPI):> - public virtual void InPacket(Packet NewPack)> + public virtual void InPacket(object NewPack)> {> - m_PacketHandler.InPacket(NewPack);> + // Cast NewPack to Packet.> + m_PacketHandler.InPacket((Packet) NewPack);> }> > Since the interface expects an object, anything can be passed around,> be it byte[], Packet or GenericMessagePacket.> > Does that still pose any issues for you?> > Mike> _______________________________________________> 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