[Opensim-dev] Upcoming work on alternative client stack

[Dahlia Trimble]

+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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080818/5bf0985b/attachment-0001.html>