[Opensim-dev] Upcoming work on alternative client stack

[Melanie]

+2. That is actually already being done, in a piecemeal fashion, as 
stuff is refactored. No *Packet types should leave the client stack.

Melanie


Dahlia Trimble wrote:
> +1 on moving all client specific protocol out of core.
> 
> On Mon, Aug 18, 2008 at 3:28 AM, Stefan Andersson <stefan at tribalmedia.se>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 Andersson
>> Tribal 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 IClientAPI?
>> >
>> > 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
>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev