Description: |
|
---|
Change the way accounts connect while keeping backwards compatibility
Review Request #1967 — Created Oct. 26, 2022 and submitted
This adds a new method to
PurpleProtocol
namedcreate_connection
which allows
a protocol to return a subclassedPurpleConnection
so it can avoid using
purple_connection_[gs]et_protocol_data
. The default implementation for this
method, just creates aPurpleConnection
with the given protocol, account,
and password.This also adds two new methods to
PurpleConnection
;connect
and
disconnect
. The default implementation for these two just call
purple_protocol_login
andpurple_protocol_close
respectively.The long term intent of this, is to have all protocol plugins subclass
PurpleConnection
and then remove thelogin
andclose
methods from
PurpleProtocol
and also removepurple_connection_[gs]et_protocol_data
.
Connected the demo account and used the account actions to test reconnecting.
Connected an XMPP account after running and at startup.
Verified that the infinite loop bug on error due to connection failure is now fixed as well.
Summary | ID |
---|---|
9c59801d841a6dd7ef90fd1c51978ea7beb0b181 |
Description | From | Last Updated |
---|---|---|
Shouldn't you check error here? It'll leak if this returns early and is set. |
QuLogic | |
%TRUE if |
QuLogic | |
Since _purple_connection_new is gone, I guess this comment can go too? |
QuLogic | |
Not sure, should we set an error here? |
QuLogic | |
Maybe here also? |
QuLogic | |
Should this not be cleared in dispose now? I suppose it might happen to work because disconnect will set it … |
QuLogic | |
Do you want to document the default disconnect here, as done for connect? |
QuLogic | |
Extra space. |
QuLogic | |
This condition is always true, because you're checking it after purple_connnection_set_state(connection, PURPLE_CONNECTION_STATE_DISCONNECTING). |
QuLogic | |
Isn't the protocol's close method called in klass->disconnect? But that method call's now after the buddy iteration, when it was … |
QuLogic |
Change Summary:
rebased
Commits: |
|
|||||||
---|---|---|---|---|---|---|---|---|
Diff: |
Revision 2 (+684 -358) |
Change Summary:
Fix the infinite loop on exit after a connection entered a failed state.
Testing Done: |
|
||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Commits: |
|
||||||||||||
Diff: |
Revision 3 (+710 -358) |
-
-
libpurple/account.c (Diff revision 3) Shouldn't you check
error
here? It'll leak if this returns early and is set. -
-
libpurple/connection.c (Diff revision 3) Since
_purple_connection_new
is gone, I guess this comment can go too? -
-
Change Summary:
address issues and better handle failed connections
Commits: |
|
|||||||
---|---|---|---|---|---|---|---|---|
Diff: |
Revision 4 (+776 -360) |
-
-
libpurple/account.c (Diff revision 4) Should this not be cleared in
dispose
now?I suppose it might happen to work because disconnect will set it to
NULL
. -
libpurple/connection.h (Diff revision 4) Do you want to document the default disconnect here, as done for connect?
-
-
libpurple/connection.c (Diff revision 4) This condition is always true, because you're checking it after
purple_connnection_set_state(connection, PURPLE_CONNECTION_STATE_DISCONNECTING)
. -
libpurple/connection.c (Diff revision 4) Isn't the protocol's close method called in
klass->disconnect
? But that method call's now after the buddy iteration, when it was previously before it in the old code that calledpurple_protocol_close
directly.
Change Summary:
rebase and address issues
Commits: |
|
|||||||
---|---|---|---|---|---|---|---|---|
Diff: |
Revision 5 (+782 -360) |
Change Summary:
explicitly clear the connection in purple_account_dispose
Commits: |
|
|||||||
---|---|---|---|---|---|---|---|---|
Diff: |
Revision 6 (+784 -360) |