Three problems I can see -
1. If keywords.txt changes ordering - everything gets busted
2. If LL makes a change to a packet, it's guarunteed broken now. (such as
if LL removes a field - a non-breaking change right now)
3. We need to release new DLL's for each update, versus new protocol and
keyword files.
I definetley agree on compile time checking however.
-Adam
Austin Jennings wrote:
On 2006/09/19, at 13:35, John Hurliman wrote:
The code generation is actual a lot closer to reality now, axial has
been doing a fair bit of work on it. By pre-generating all the code
it should remove the need for the external keywords.txt/
message_template.msg to be shipped with applications, and it produces
code optimized for each packet (without the overhead of reflection).
The other side of this is an optional update server that produces the
latest stable libsecondlife.dll (updated after every
message_template.msg update) for client apps to take advantage of.
The details can be hashed out some more in a separate thread since
this is a big change.
That's me. For those who haven't been following all of the discussion,
I'll summarize the idea. First of all, what I mean by "protocol code"
is just the low-level stuff responsible for converting back and forth
between the UDP packets we use the communicate with SL and the Packet
objects we use internally in libsl.
As I'm sure you're all aware, we're currently representing packets in
libsl as hashtables of hashtables of fields. Every time libsl starts,
it reads in the keywords.txt and message_template.msg files and builds
up a huge internal data structure representing what types of packets
are available and how they're structured. Whenever libsl sends or
receives a packet, it digs into that data structure to figure out which
fields in which hashtables correspond to which bytes. It works fine,
but there's a few problems:
- It makes it easy for developers using libsl to make mistakes. If you
give libsl a short when it wanted an int, you don't know about it until
you get a (rather confusing) error at runtime. It'd be nice to get
those errors at compile time.
- It's not terribly fast, since there's a lot of runtime reflection
going on. The protocol code is pretty fundamental, so it'd be nice if
it didn't have to go through all those steps every time it sees a packet.
- You have to ship keywords.txt and message_template.msg along with
every libsl app, and the app will error out (violently) if it's not run
from the same directory as those files. It'd be nice to just build
everything into the .dll.
- It's a bit buggy. Packets are getting truncated and endianness bugs
keep popping up over and over. It'd be nice if we could go back and
redo the delicate parts, knowing now where we have to be more careful.
So I've been working on a fresh implementation of the protocol code
that addresses these four issues. The general idea is that, instead of
reflecting on the keywords/message_template data at runtime, we write a
tool that turns those two files into a bunch of C# classes-- one for
each type of packet. The blocks and fields will just be normal object
properties. If you wanted to make a ChatFromViewer packet, it'd look
something like this:
ChatFromViewerPacket p = new ChatFromViewerPacket();
p.AgentData.AgentID = myAgentID;
p.AgentData.SessionID = mySessionID;
p.ChatData.Message = "hello, simulator"
p.ChatData.Type = 1;
p.ChatData.Channel = 0;
And that's it. Since the fields are normal object properties, you'll
get an error at compile time if you try to stick a vector where it
wanted a quaternion. The ChatFromViewerPacket class knows how to turn
itself into a UDP packet, and it knows how to construct itself from a
UDP packet. It should be faster than the old method, and since it's a
class that's compiled into the dll, you won't need to keep the
keywords/message_protocol files around anymore. There's a couple other
bonuses too; for example, you'll get auto-completion on packet and
field names in any IDE that supports it.
Of course, it's not done yet. I wrote the easy parts, but I've been a
bit too busy to dive into the tricky bits (namely, all the stuff that
wound up bug-ridden the first time around). Once it is working, I'll
merge it in alongside the current protocol implementation--at first
you'll be able to use whichever one you want (that'd be a lot of code
to rewrite if I forced it on you overnight)--and if people like it,
we'll phase out the old code. At least, that's the plan in a nutshell.
-- Era Pixel
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
http://www.libsecondlife.org/
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
http://www.libsecondlife.org/
