| Age | Commit message (Collapse) | Author |
|---|
|
|
|
mess\nthings up. We shall see. In other news, I'm adding a Bu::StreamStack class\nthat will let you easily manage dynamic stream/filter sets.
|
|
servers that run for weeks or more.
|
|
Unfortunately this breaks some programs that accessed the client internal
buffer directly. Overall it's much, much more efficient, so it's worth it,
maybe we'll find a good workaround later.
|
|
|
|
copyright 2007-2008.
|
|
the filter chain, I'm going to go ahead and make that optional coming up.
|
|
chain on the base stream, which for the moment is a socket.
I also demonstrate this in the new rot13 test, with a rot13 filter, and a simple
echo protocol.
|
|
|
|
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.
|
|
exception related code that's been annoying me. You should no longer have to
include any exception header explicitly for normal operations, every class that
has it's own exception to throw defines it in it's own headers.
This may break some code that uses libbu++, but it's an easy fix, just delete
the include for exceptions.h. Sometime soon I would also like to move from
Bu::ExceptionBase to Bu::Exception, but that will affect a lot more code than
this change did.
|
|
|
|
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.
|
|
|
|
Client for buffering. The Bu::Client has also been made a little more reliable.
The logger should get a few more tweaks, but it works fine for now, the hex dump
could stand another tweak or two.
|
|
|
|
general Http handler working, the test for the moment, is Doxysrv, I'll probably
write a cute little stand-alone one in libbu++ later as a demo/test.
|
|
has been fixed, it now safely disconnects after emptying the Client's outgoing
buffer.
Added some more helpers to Bu::FString.
Added the beginings of ProtocolHttp using a new method for processing protocols
that's based more strongly on an NFA state machine, this makes sense, but I
never had the desire to actually try implementing it before. It's working
pretty well.
|
|
|
|
|
|
|
|
is less ugly.
|
|
working in optimal condition...
|
|
as a convinience.
|
|
things from it. The plugger had yet another bugfix...plugger...
|
|
the old one in pretty much every way, and better in most. It's much easier to
understand. And the atom class is better.
|
|
now when the end has been reached.
|
|
to include many more state indicators and caps queries, and everything is
working better in general.
|
|
I'm going to do it over from scratch, that was just painful. Also, started in
again on the server system, it's looking pretty good, already got connections
working, next up is managing data flow through clients and protocols!
|
|
actually interacting with clients, and the Client class is almost there, except
that it doesn't really do anything yet.
|
