| Commit message (Collapse) | Author | Age | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
sending, that's my next task. You can use proxies when receiving though!
I also changed the buffering strategy. Previously receiving continued till some
buffer limit was reached, now only one message is received and receiving stops
till it is delivered. This keeps the buffering space per file transfer to a
minimum(currently 4k). Makes sense when used on a public server. For public
servers a throughput maximum would also be interesting...
|
| |
| |
| |
| |
| | |
only one buffer of 2k per transfer now.
|
|/
|
|
|
|
|
|
|
|
|
|
| |
* move from out_of_data to is_writable, eliminate buffers
* implement "transfers reject [id]"
* documentation in commands.xml
* implement throughput and cummulative throughput boundaries
* feature discovery before sending
* implement sending over a proxy
(proxy discovery, socks5 client handshake for sending, activate message)
* integrate toxik-mek-ft
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
only a few changes to bitlbees code, mainly the addition of the "transfers"
command.
This is known to work with Kopete, Psi, and Pidgin (formerly known as gaim).
At least with Pidgin also over a proxy. DCC has only been tested with irssi.
IPV6 is untested but should work.
Currently, only receiving via SOCKS5BYTESREAMS is implemented. I'm not sure if
the alternative(in-band bytestreams IBB) is worth implementing since I didn't
see a client yet that can do it. Additionally, it is probably very slow and
needs support by the server as well.
|
| |
|
|
|
|
|
|
| |
from other BitlBees won't be picked up accidentally. Might also want to
randomize the per-packet IDs because they're still predictable.
|
|
|
|
|
|
| |
<presence type=unavailable> tag properly and keeps showing the buddy as
on-line. (When the tag comes from a bare JID.)
|
|
|
|
|
| |
I ever need SHA256 ;-)).
|
| |
|
|
|
|
|
| |
aliasing because there are too many warnings about it. :-P)
|
|
|
|
|
| |
change. (Patch from arnau)
|
|
|
|
|
| |
(which I do quite often when testing stuff).
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| |
| | |
implement the Jabber hooks.
|
| |\ |
|
| | | |
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
(NULL pointer dereference).
|
| | | |
| | | |
| | | |
| | | |
| | | | |
(only presence so far) errors.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
IRC-specific stuff into the Jabber module). Only using this in the MUC
code for now because this only works if the IM module can somehow convert
the cleaned up handle back to the original one.
|
| | | | |
|
| |\ \ \ |
|
| | | | | |
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
a debian/ tree and a merge from Jelmer (mainly unittest stuff).
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
channel name generation code in root_commands.c and fixed one memory leak
in jabber_buddy_remove_bare().
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
the current one (otherwise the dedupe function will dedupe the nick
against itself).
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
cleaning up of groupchats isn't done very well yet, but this will at
least keep things sane.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
fixes a bug reported by James Teh in the monster ticket #20. There's no
proper garbage collection yet in the Jabber conference code, really have
to do that soon. :-(
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
one's still there. Not sending offline notifications is great, but updating
the away state info is even better. :-)
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
that list. And adding some const stuff in the xmltree functions.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
anymore.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
where some of them are down.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
work. This also solves the issue of underscores appearing and disappearing
in their nicknames when people leave/join a chat.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
way to set the nickname in time before BitlBee sends the JOIN.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
nickname generation. IM fullnames and IRC nicknames are just *different*.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
nicknames for chatroom participants. There'll probably be a lot of
underscores now, but this is by far the cleanest way to implement this, I
think. At least now whispers will work properly. Also using this function
call to set names for ICQ contacts in a slightly saner way.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
actually be recognized properly. This is running on my work machine for
a few days already.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
(without any @server part) to your contact list and you'll see all XMPP
traffic going in and out, and messages sent to the buddy will be sent as
packets to the server.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
doesn't deal with it very well, and I don't really know yet how I'll
solve this... :-(
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
conferences the user's in.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
used the GLOBAL IM connections list, allowing user A to interfere with
user B's groupchats if running in daemon mode. I can't believe this was
still there...
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
with anonymous rooms (ie about 95% of all available Jabber chatrooms?).
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Just don't use this, you're really not going to like it. :-)
|