[Opensim-dev] Upcoming work on alternative client stack

[Frisby, Adam]

That's a good question - however there's actually no clear license over that file. LL have dictated that the source is GPL, the art is CC-BY-SA, but the remainder is somewhat gray. (However it's worth noting that the msg_template is definitely available on wiki.secondlife.com under CC-BY-SA, although in small pieces spread around.)

Perhaps someone from Linden Lab would like to chime in here?

Regards,

Adam

> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> bounces at lists.berlios.de] On Behalf Of Kyle Hamilton
> Sent: Sunday, 17 August 2008 1:46 PM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Upcoming work on alternative client stack
>
> I would avoid generating C# and C/C++ code from message_template.msg.
> The entire distribution (including that file) is only made available
> under GPL; any programmatic derivation from it (and a programmatic
> transformation turns it from 'reference' to 'source code') could be
> held to place the derivative under the GPL as well.
>
> Maybe someone can ask if they can make an exception for that file?
>
> -Kyle H
>
> On Thu, Aug 14, 2008 at 2:38 PM, Mike Mazur <mmazur at gmail.com> wrote:
> > Hello,
> >
> > (Could it be? Are the mailing lists working again? I wanted to send
> > this message last weekend.)
> >
> > Some of you may already know, I've started working on an alternative
> > client stack. This alternative stack does not use libomv's Packet
> > class to move packets around. The buffers which are written to by
> > socket functions are passed around instead, with functions available
> > for extracting or writing data to the buffers.
> >
> > These functions are provided by a package currently codenamed
> "funsl".
> > Johan has written a compiler[1] which generates C# and C/C++ code
> from
> > LL's message_template.msg file[2].
> >
> > We're doing this because we believe the creation of a Packet object
> > for each transferred packet impacts performance, particularly when GC
> > events occur.
> >
> > As I'm working on this I found that libomv's Packet class is used
> > outside the client stack, namely in
> OpenSim/Framework/ClientManager.cs
> > and OpenSim/Framework/IClientAPI.cs (among other places). Since our
> > client stack needs to implement these interfaces too, and needs to
> > call ClientManager methods, those libomv Packet references get in the
> > way. I would like to factor them out.
> >
> > Please allow me to give you an example, inspired by changeset r5785.
> > ClientManager had a method, InPacket(), defined as below:
> >
> >     public void InPacket(uint circuitCode, Packet packet)
> >     {
> >         IClientAPI client;
> >         bool tryGetRet = false;
> >         lock (m_clients)
> >             tryGetRet = m_clients.TryGetValue(circuitCode, out
> > client); if (tryGetRet)
> >         {
> >             client.InPacket(packet);
> >         }
> >     }
> >
> > This method receives a circuit code and passes the packet to the
> > IClientAPI instance associated with said circuit code.
> >
> > Why should the ClientManager have knowledge of Packet? It's not in
> the
> > client stack, it only provides access to the clients. Therefore I
> > changed the method as follows:
> >
> >     public void InPacket(uint circuitCode, object packet)
> >     {
> >         IClientAPI client;
> >         bool tryGetRet = false;
> >         lock (m_clients)
> >             tryGetRet = m_clients.TryGetValue(circuitCode, out
> > client); if (tryGetRet)
> >         {
> >             client.InPacket(packet);
> >         }
> >     }
> >
> > Instead of expecting a Packet object for the second argument, we
> > expect any object. Naturally the signature of the InPacket() method
> in
> > the IClientAPI interface has also changed. The cast from object to
> > Packet (or byte[] in my case) is done in the class which implements
> > IClientAPI, namely
> > OpenSim/Region/ClientStack/LindenUDP/LLClientView.cs, where
> InPacket()
> > has been changed as follows:
> >
> > -        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);
> >     }
> >
> > InPacket() is the first method that has been changed so far, but
> > others will need to follow (OutPacket(), SendSimStats(),
> > ProcessInPacket(), etc).
> >
> > Please rest assured these changes don't break existing functionality,
> > just factoring out some libomv Packet references which currently live
> > outside the client stack.
> >
> > Any thoughts or concerns?
> >
> > Thank you,
> > Mike
> >
> >
> > [1] If you are interested in the source for the compiler, written in
> > LISP, just ask ;)
> > [2]
> >
> http://svn.secondlife.com/trac/linden/browser/release/scripts/messages
> > _______________________________________________
> > 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