Some thinking later and I've split the network code into three files.

If anyone wants to play around with it, I have a (temporary) extra ASDF definition to make it possibel to load noctool and noctool-with-network separately (makes it slightly easier to find network-specific compilation issues), I'll paste it in towards the end.

Now, what I've done, to make the protocol dispatch easier (hahaha) to follow, is a dispatch table, keyed off the protocol message header and a macro taht defines handlers.

The defhandler macro looks like this: (defhandler <function name> (<protocol header> <rest> <of> <message>...) ... function body goes here)

This does two things, it defines a function <function name>, with CONN as the first argument (in most cases, you need to know what connection to send a reply back to) and the message type thingie declared as ignorable (since, most of the time, it's only used for dispatching, anyway).

Not very tested, as of yet, I'll probably need to frob around with how to retrieve and set proxy objects, but...

And here's the system definition (once the network code is a bit more stable and "with it", I'll merge this into the main system definition, I won't check this temp definition into CVS): (in-package :asdf)

(defsystem "noctool-network" :depends-on ("noctool") :components ((:file "network-globals") (:file "network-utils" :depends-on ("network-globals")) (:file "network" :depends-on ("network-utils" "network-globals"))))

//Ingvar