AUTHORS, CONTRIBUTORS: still useful, add people from git log, clean up.
LICENSE: Google doesn't really grant you shit anymore. The EU doesn't
have software patents either, so it doesn't affect me directly.
README, doc.go: erase mentions of unmaintained xgbutil.
NewRequest says you can avoid reallocating a new buffer for each request by calling it directly.
This is not true if req.seq is closed before req.buf is read.
Fixes#9.
This makes shutdown a little more graceful, but there's more
work to be done here. Namely, all outstanding cookies need to
be given the error, otherwise they will block forever.
Just enabling or disabling logging falls short of the power of
interfaces of go. A user is forced to either accept the logging to
stderr in the format defined by xgb or disable logging alltogether. By
exporting the logger, we can actually let the user decide where to log
in what format.
goofing here.
What I'd personally like to do is just use an "infinite" channel. That
is, push the limit of how many events can be processed to the machine
and not set an artificial limit in XGB. Some day...
and falling back to a blocking send inside a goroutine.
This really needs to be fixed. The situation only arises when events are
sent and aren't pulled off the channel using {Wait,Poll}ForEvent.
Namely, if the event send blocks, the entire program will deadlock.
Using a goroutine is not ideal because we lose a guarantee of order:
that events are processed in the order of their arrival. However, it
seems OK as a temporary band-aide for a situation that probably doesn't
arise too often.
What I need to do is implement a dynamic queue. Here is a reference
implementation: http://play.golang.org/p/AiHBsxTFpj
