| Age | Commit message (Collapse) | Author |
|---|
|
fstring, and updated the copyright notice to extend to 2011
|
|
that were using fstring, I hope.
|
|
copyright 2007-2008.
|
|
implement in Bu::ItoServer, but I'll get to it. Basically you can trigger a
"tick" any time you want and it will propegate as an onTick event to all active
clients. You can also have these generated automatically everytime the system
passes through a polling cycle. In this case, you should never ever write
data to the socket every tick. It will cause your program to go bursurk.
|
|
ok, nids is still in flux, they'll be gone soon).
|
|
|
|
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.
|
|
|
|
to include many more state indicators and caps queries, and everything is
working better in general.
|
|
into src as it's fixed and re-org'd. This includes tests, which, I may write a
unit test system into libbu++ just to make my life easier.
|
|
and the connection monitor work in two-way-mode. Effectively you should be able
to write systems that both serve and initiate connections, and only write one
protocol.
|
|
that wants to send messages to a containing programlink.
Also fiddled with other things...aparently.
|
|
|
