Open
Bug 1227973
Opened 9 years ago
Updated 2 years ago
Dynamic registration of Protocols
Categories
(Chat Core :: General, enhancement)
Chat Core
General
Tracking
(Not tracked)
ASSIGNED
People
(Reporter: freaktechnik, Assigned: freaktechnik)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
2.04 KB,
application/x-xpinstall
|
Details | |
12.68 KB,
patch
|
Details | Diff | Splinter Review |
I've been developing a protocol extension that's bootstrapped (actually SDK based, but that needs more work elsewhere) and decided to make it possible to register and unregister protocols for bootstrapped extensions.
This patch adds observers for protocol registrations and unregistrations in the relevant places. It swaps out the previous protocol and protocol account implementation of an imAccount in both cases and updates the accounts status (connecting it if autoconnect is enabled etc.).
I haven't got around writing tests for it yet, but I promise to do that next. Current tests passed for me.
I've also attached a minimal bootstrapped protocol, based on the jsTestProtocol.
There are a few bits that I'm not completely sure of:
- It might be nicer to emit a custom observer notification from imCore when protocols are registered and unregistered.
- prpl-jabber currently gets picked up by the dynamic registration, not sure why.
- There is currently an error with the /protocol prpl, which I think is somehow related to the purple protocols, not sure there. It doesn't seem to affect any functionality (I don't build the purple extension).
Assignee | ||
Comment 1•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Attachment #8691960 -
Flags: feedback?(florian)
Assignee | ||
Comment 2•9 years ago
|
||
Soi the prpl-jabber thing might not be an issue, or it might be one. It's from the forcePurle option for prpl-jabber and I don't have libpurple built. But that doesn't mean it won't break libpurple jabber (I'll have to try that).
Assignee | ||
Comment 3•9 years ago
|
||
I've noticed one issue with this patch: it does not update the File menu when a protocol is removed. Though that's probably in theory not a related bug.
Assignee | ||
Comment 4•9 years ago
|
||
I restructured the code so it mostly lives in a method of imAccount called "_swapProtocol". This method is also used in the contructor of the imAccount, since mostly the same things are run.
I would like to eliminate the third arguemnt, however with the current handling of how the protocol is removed it is not guaranteed, that the protocol has already been removed from the cache in imCore. One way to do that would be to check if a protocol is not unloaded before returning it in the imCore. I'm not sure if there's an efficient way to do that.
Further it'd be nice if accounts could be properly disconnected when a protocol is removed, given the prplAccount hasn't been nuked yet. However this would require waiting for the prplAccount to declare the imAccount as disconnected and I'm not sure how to do that nicely.
Attachment #8691960 -
Attachment is obsolete: true
Attachment #8691960 -
Flags: feedback?(florian)
Attachment #8747919 -
Flags: feedback?(florian)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → martin
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Updated•6 years ago
|
Attachment #8747919 -
Flags: feedback?(clokep)
Updated•5 years ago
|
Attachment #8747919 -
Flags: feedback?(florian)
Attachment #8747919 -
Flags: feedback?(clokep)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•