On 2006/09/19, at 19:27, Adam Frisby wrote:
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.
All true, but practically speaking, releasing a new dll isn't any
harder than releasing two new protocol files. You'll have to update
and restart your application either way, and since libsl provides
abstract interfaces to a lot of those packets, in many cases you'd
have to update libsecondlife.dll whether the actual protocol
information were built in or not. Of course, this is where the auto-
updater that John mentioned comes and saves the day.
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/
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
http://www.libsecondlife.org/
