Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Client Server -- the path is painful



I've been working on client -- server for most of the weekend because
I've been sick and can't get real work done.
As of right now, I have map display, info lines, and the middle status
window above the map working.  I partially have keys input working;
more on that later.  With luck I'll have many of the remaining pieces
working soon, and I'll be testing out performance over a 14.4 modem.

This message helps describe what I've done, and what could be done to
help:
1. I did not follow the protocol as specified in the protocol docs, I
used my own library which lets me pass around typed lists of stuff,
and I really didn't feel like parsing lots of input lines.
Furthermore, implementing protocol along the lines of the code already
existing let me get things going faster.
2. I built this entirely on a new port with a new number, I modified
the player struct to have an eric_server value which is a client id --
this allowed for good separation between the new client server stuff
and the old code.  
3. I modified the old code so that instead of calling X routines, it
called my routines if there was a positive eric_server value; this
involved modifications to player.c, xio.c, and main.c.
4. I abused the xio.c and x11.c stuff so that it did what I want; in
particular, the protocol doesn't send faces until neccesary, and it
only supports pixmaps,no split windows, etc. 
Amusingly enough, the startup with the client
is faster than the startup normally because I don't setup all the
faces.
-----
So if you've read this far, you're probably thinking either:
1. Hey that's cool, how can I help; or
2. Hey that's cool, when can I get it; or
3. Hey why didn't you work within the protocol and why doesn't it do
blah blah blah.

I'll answer these in reverse order
3. Because I don't care, I wanted to see it work.
2. That depends on how much time I have to spend on it, and how much
help I get from other people.
1. There are lots of things that could be done.  The biggest set being
cleaning up the bogosities inside of player.c; for example,  I split
the function handle_player into three routines, one which handles
keypresses and one which handles buttons.  Those two functions are
both over 250 lines.  It would be nice if they were further divided.
In particular, removing the xevent structure from player.c would do
wonders toward making client-server more palatable.  The second thing
would be eliminating all of the uses of KeyCodes in the keyboard
handling routines; if you don't have an X display, you don't have
keycodes; moreover getting keycodes requires round trips to the
server.  I'm going to get around this by sending every single keysym
converted to a keycode over in an initialization message. This is not
particularily efficient.  Other general cleanups which eliminate all
the global variables would also make things nicer.
If you'd like to help, I'm looking for a place to put all the stuff
for anonymous ftp so that people can get it and continue from where I
am; please tell me which piece you want to fix, and how long you
expect to take doing it.  
--
Independant of how much help I get, I'd expect to have real (if
painfully hacked up) client server by the end of the week.  I'll try
to make the client module available to everyone so that it can be
tried out, and I'll send the whole shebang off to Mark.
--
Long live client server hackerfoo;
Some of the code (to quote Pink Floyd) "Filled me with an urge to
defecate" 
pass your hacker saving throw and you can avoid looking at lots of the
code. 
          -Eric 
*********************************************************
"It seemed like a good idea at the time"
           -The Mad Hatter
"Yes, you're very smart.  Shut up."
           -In "The Princess Bride"
*********************************************************