| Age | Commit message (Collapse) | Author |
|---|
|
lot of problems. This may require a little more research, but basically, you
can't just call them inline wherever you'd like. I managed to get it to work
by providing simple one line wrapper functions for each function we acquired as
a pointer. Crazy mess. Anyway, it should load the library just once now, and
Bu::Socket looks a little bit cleaner, but not a heck of a lot.
I also added some more docs and removed the author references.
|
|
version of gcc complained about them, none of these changes will break backward
compatibility, so I fixed them.
I added more docs too, it seems.
|
|
sever/client-link system.
|
|
|
|
done yet. The Client class now supports a function called getLink() which
returns a ClientLink object. This object may then be passed off to any other
class and called to send messages to that client object. It is threadsafe if
ItoServer is being used, and not for Server. Sending a message via a
ClientLink calls the onMessage function on the assosiated protocol.
Note that sending messages from within protocol event handlers or functions they
call, while safe, may be slow and it's reccomended that you avoid this.
|
|
|
|
the existing docs. Taking advantage of some of the cooler extra features of
doxygen I've started writing extra how-to pages covering working with sections
of the library. Also, I started grouping the classes by function so they show
up on the Modules page together, very cute.
|
|
connections and actually cleans up behind them when they're all done. Seems
important. It also will cleanup any lingering sockets that are laying around
at destruction time, although right now unless you force-stop the server thread
there is no way to interrupt it. That'll come in a bit.
|
|
very similarly to the Bu::Server class, except that every incoming connection
gets it's own thread. This functionality may have to be tuned later, to allow
for maintaining a pool of connections as an option, but this is fine for now.
|
