| Commit message (Collapse) | Author | Age | Lines |
... | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
|\ \ \ \ \ \ \
| |_|_|_|_|_|/
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
setting, which makes BitlBee send a message to bare JIDs if there was no
recent seen activity from any of the person's resources. This should fix
most issues with messages going to the wrong resource (i.e. someone's
mobile phone instead of something more sensible).
|
| |\ \ \ \ \ \ |
|
| | |_|_|_|_|/
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
a activity_timeout setting. Now, messages to someone who hasn't spoken for
a while will be sent to his/her bare JID, usually resulting in a broadcast.
This should fix issues with messages sometimes arriving on someone's
Crackberry/Android/etc instead of some place s/he's paying attention to.
Last, the activity timer is only reset on incoming messages.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
because some very picky jabberd's don't like it. (Fixes Bug #569)
|
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
jabberd's including Zimbra's. Thanks to jMCg and balzar in #bitlbee for
helping with figuring this out.
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | | |
more consistent. Except for free-for-chat, which is nuts anyway.
|
| | | | | |
|
| |_|_|/
|/| | |
| | | |
| | | |
| | | | |
a password in the IRC JOIN command).
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
MD5 hashes instead of a known MD5 hash with a number. Just to make it
harder to confuse BitlBee by sending it faked responses to packets.
|
| |_|/
|/| |
| | |
| | |
| | | |
numbers, adding 80 and 443. Partially closes #265.
|
| | |
| | |
| | |
| | |
| | |
| | | |
chatroom. Until now they were ignored, which might make backlogs a little
bit confusing.
|
| | |
| | |
| | |
| | |
| | |
| | | |
clients interested in capabilities can cache discovery info, so they don't
have to ask about it every time you/they log in.
|
| | |
| | |
| | |
| | |
| | |
| | | |
cached packets are removed after about ten minues instead of something
between one and two minutes. Closes one issue in #354.
|
| | |
| | |
| | |
| | |
| | |
| | | |
ignored if the connection's dead already. Necessary if using GLib for event
handling for now. :-/
|
| | | |
|
| |/
|/|
| |
| |
| | |
to chat_invite).
|
| |
| |
| |
| |
| |
| | |
jabber_chat_by_jid() (with the right name) to conference.c, I don't know
what it was doing in jabber_util.c.
|
|/
|
|
|
| |
IQ packets to jabber_util so I can reuse it for certain presence packets.
|
|
|
|
|
|
| |
from other BitlBees won't be picked up accidentally. Might also want to
randomize the per-packet IDs because they're still predictable.
|
| |
|
|
|
|
|
| |
(only presence so far) errors.
|
|
|
|
|
|
| |
channel name generation code in root_commands.c and fixed one memory leak
in jabber_buddy_remove_bare().
|
|
|
|
|
|
|
| |
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. :-(
|
| |
|
|
|
|
|
|
|
| |
(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... :-(
|
|
|
|
|
| |
with anonymous rooms (ie about 95% of all available Jabber chatrooms?).
|
|
|
|
|
| |
Just don't use this, you're really not going to like it. :-)
|
|
|
|
|
|
| |
will come tomorrow. It compiles, I'll leave the real testing up to someone
else. ;-)
|
| |
|
|
|
|
|
| |
insensitivity. Probably not complete yet...
|
| |
|
|
|
|
|
|
| |
makes it easier to find out if an event handler has to be called for a
reply packet.
|
| |
|
|
|
|
|
|
|
| |
list, proper checking (and handling) of events related to buddies that
aren't "hashed" yet, limit checks on priorityto setting, renamed JEP85
to XEP85, support for more XEP85 states.
|
|
|
|
|
|
| |
login, and now sending proper error responses to IQ packets we can't
handle.
|
|
|
|
|
|
|
| |
budd_by_jid(), added a full_jid property to easily address that resource
without having to rebuild the full JID every time and implemented typing
notification shite.
|
|
|
|
|
|
|
|
|
| |
means the buddy won't show up offline when one resource goes down (while
there are still others available). It also remembers away state
information for every separate resource. Later this system will be used
to keep track of client capability information (Typing notices, yay...)
and who knows what else.
|
|
|
|
|
| |
mess in iq.c!
|
|
|
|
|
|
|
| |
event handlers that can be set when sending a packet to handle the reply
to this specific packet. This should allow me to make the iq handler a
lot cleaner.
|
|
|
|
|
|
|
| |
by any client I know of. Also, they're already working on a (probably
completely incompatible) standard: JEP-191. Maybe BitlBee will implement
it too some day...
|
| |
|
|
|
|
|
| |
connecting to Google Talk.
|
| |
|
|
|
|
|
| |
seem to be completely like how it works on other IM networks.)
|
|
|
|
|
| |
to work perfectly though.
|
|
|
|
|
|
| |
setting has to be finished, plus an ssl_starttls() function for the other
SSL libraries (this code will only compile with GnuTLS for now).
|