On Wednesday 18 February 2009 09:20:32 George Goldberg wrote:
> Since there have been no responses to this thread for a week now, I'm
> going to assume that there is nothing more that needs adding to whats
> been said - if there is, please do speak up!
>
>
> On Mon, Feb 9, 2009 at 6:41 PM, George Goldberg
>
> <[email protected]> wrote:
> > 3) Decibel chooses which Contact Manager to use to open a connection
> > when connecting one of your accounts. e.g. it allows any jabber
> > connection manager that is installed to be used to connect my jabber
> > account: [email protected].
>
> I've been thinking about this feature a bit, and it seems to me that,
> although the idea behind it is nice, in practice it is not possible,
> simply because  there is no standard or consitent approach to naming
> the parameters that a connection manager accepts, so an account
> created originally with parameters for one connection manager may not
> work with another, and may even behave unpredictably with an other if
> they use the same parameter name for a parameter with a different
> function. Since the Decibel daemon cannot have any knowledge of what
> parameters mean on different connection managers, I think that it is
> best to drop this feature.
>
> To illustrate this problem, compare the parameters for haze, protocol
> local-xmpp and salut.
> Both are doing the same protocol - local xmpp.
>
> Haze parameters:
> account (required)
> first-name (required)
> last-name (required)
> email
> AIM
> jid
>
> Salut parameters:
> nickname
> first-name (required)
> last-name (required)
> jid
> email
> published-name
>
> As can be seen, although they have the two name parameters in common,
> haze has an extra required parameter, "account" which is not present
> on salut. What should happen if an account created for salut tries to
> connect with haze and can't because of a missing required parameter?
> All the parameters that might be required can't be known at the
> account creation stage because that would require knowing every
> possible connection manager, both present and future, and what
> parameters it requires.
>
> So, in summary, I think it would be a *lot* simpler just to drop this
> piece of functionality altogether. It is a lot of trouble to make work
> and I don't think it is useful enough to warrant these problems.
>
> How does everyone else feel about this?
>
>

That's fine by me.
--
Matt

_______________________________________________
Decibel mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/decibel

Reply via email to