| Commit message (Collapse) | Author | Age | Lines |
|---|
| ... | |
| | |
|
| | |
|
| |
|
|
|
| |
This enables various format string security checks by the compiler in
attempt to avoid run-time failures.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Currently, the plugin relies on the 'chat add' root command in order to
create a new group chat. Aside from being an ugly hack, this prevents
the plugin from being able to automatically join the bitlbee user into
the newly created channel. In order to allow for automatic joining, the
plugin should directly create the group chat, rather than relying on
the "chat add" root command.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, all roots commands require an account identifier in order to
operate. However, more times than not, there will only be one Facebook
account per bitlbee user. The plugin should allow for the short handing
of root commands, where the account identifier is negated when there is
only one active Facebook account.
This patch allows for users with only one active Facebook account to
negate the account identifier. The negation of the account identifier
is optional. If there is more than one active Facebook account, the
root commands behave as they currently do, and require an account
identifier.
|
| |
|
|
|
|
|
|
| |
Currently, it is just assumed that the account is online, however, this
is not always the case. If one of the root commands attempts to act on
an offline account, it will typically lead to a segmentation fault. To
guard against this, an additional check must be added to ensure the
account is actually online.
|
| |
|
|
|
|
|
|
|
| |
This removes certain topic subscriptions which are of no importance to
this plugin. This results in the usage of slightly less bandwidth.
This also forcibly unsubscribes from the message notifications topic,
which seems to cause the connection to die out randomly when messages
are sent.
|
| |
|
|
|
|
| |
As of now, the connection error code is only a general error code. It
should be the actual error code retrieved from the MQTT service. This
was an oversight when implementing the original MQTT interface.
|
| |
|
|
|
| |
The connected state should be reset when the connection is closed. This
was an oversight when implementing the original MQTT interface.
|
| |
|
|
|
|
|
|
|
| |
As it stands, a connection is declared as being timed out if it has not
heard back from the server with a ping response in one keep-alive time
interval. However, the MQTT specification states that a connection is
only declared timed out after one and a half time intervals. While the
effects of this oversight may not be immediately present, over a period
uptime, the connection may fall victim to preemptive timeouts.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
