Opened 11 years ago

Last modified 10 years ago

#5667 new enhancement

Decouple plugin name from protocol supported

Reported by: felipec Owned by:
Milestone: 3.0.0 Component: libpurple
Version: 2.4.1 Keywords:
Cc: pacho

Description

So more than one protocol plug-in can support the same protocol

Change History (10)

comment:1 follow-up: Changed 11 years ago by datallah

I guess I don't know what benefit this would have. How would you differentiate them?

comment:2 Changed 11 years ago by felipec

You could distribute a development branch of a prpl so users can easily try it. Also it helps to alternative prpl implementations.

You differentiate them the same way you differentiate them right now: by the name.

comment:3 Changed 11 years ago by datallah

Maybe I'm misunderstanding something... If you had two plugins with an id "prpl-msn", how would libpurple know which one to use?

comment:4 Changed 11 years ago by felipec

There would be "prpl-msn" and "prpl-msn-pecan".

What I'm suggesting is the addition of a "protocol" field. That would be the only thing in common, not the id.

comment:5 Changed 11 years ago by felipec

So?

comment:6 Changed 11 years ago by datallah

I'm still not getting what this would do. Why does the core need to know what "protocol" a plugin is implementing?

comment:7 Changed 11 years ago by datallah

  • Milestone set to 3.0.0

In IRC, Felipe pointed out that it would allow multiple implementations of the protocol to share Smiley themes.

What else would we want to tie to this "protocol" field?

comment:8 Changed 11 years ago by felipec

The milestone should not be 3.0.0, now new fields can be added without breaking API compatibility.

Something like list_icon could be used, actually, even list_icon can be used, as "msn" is exactly what is needed to know the protocol implemented.

comment:9 in reply to: ↑ 1 ; follow-up: Changed 10 years ago by resiak

Replying to datallah:

I guess I don't know what benefit this would have.

Felix's SoC project, prpl-telepathy, provides alternative implementations of most of the protocols that ship with libpurple. Right now, this means that there are two entries in the protocol list for each protocol.

That said, switching transparently between two implementations of a protocol is unwise: they will probably have different options, for starters.

comment:10 in reply to: ↑ 9 Changed 10 years ago by felipec

Replying to resiak:

Replying to datallah:

I guess I don't know what benefit this would have.

Felix's SoC project, prpl-telepathy, provides alternative implementations of most of the protocols that ship with libpurple. Right now, this means that there are two entries in the protocol list for each protocol.

That said, switching transparently between two implementations of a protocol is unwise: they will probably have different options, for starters.

Yes, the account options should be per prpl, but smiley themes should be per protocol, not prpl.

Perhaps the contact list should also be per protocol, but I'm not so interested in that.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!