Dynamic registration of Protocols

ASSIGNED
Assigned to

Status

enhancement
ASSIGNED
3 years ago
2 months ago

People

(Reporter: freaktechnik, Assigned: freaktechnik)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

3 years ago
Posted patch dynamic-accounts-v1.patch (obsolete) — 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

3 years ago
Posted file test-provider.xpi
(Assignee)

Updated

3 years ago
Attachment #8691960 - Flags: feedback?(florian)
(Assignee)

Comment 2

3 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

3 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

3 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

3 years ago
Assignee: nobody → martin
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #8747919 - Flags: feedback?(clokep)
You need to log in before you can comment on or make changes to this bug.