Proposal for an extended callbacks field

[Etan Reisner]

On Thu, Jul 26, 2007 at 12:05:25PM +0200, Andreas Monitzer wrote:
> On Jul 26, 2007, at 07:28, Etan Reisner wrote:
<snip>
> Yes, but the core would still have to call the ui callback as well.
> There has to be a way to pass the function for this ui callback.

Yes, but the callback 'passing' can be handled as a ui_op or a signal
callback just as easily as it can be passed into the prpl_info function,
only both of those change something much less central and are a generic
solution to a class of problems rather than a specific solution to a
specific problem. They are also both more flexible.

> >The fact that your currently implemented method is an ugly one (and
> >by the
> >way not at all the one I suggested when this first came up which
> >was to
> >have a purple_account_registered function and an associated signal
>
> I implemented the one Sean suggested.
>
> >(and possibly a ui_op if needed)
>
> I wasn't allowed to add something there due to the limited amount of
> reserved fields.

I'm assuming you are referring to an initial conversation with Sean
because in the discussion thread about this issue he very clearly stated
that he had reconsidered and that using a ui_op would be an appropriate
thing to do. I think it is useful to note that there is no need to add a
ui_op for this because the ui could just use a signal if we really didn't
want to mess with the padding in the ui_op struct right now.

<snip>

> >Ad-hoc commands are very much something I would like to get pidgin to
> >support, but I can not see my way clear to adding them to the
> >prpl_info
> >struct because they are inherently protocol specific.
>
> The underlying issue is: Should the prpl struct be the subset of the
> features all protocols support, or should it be the superset of all
> of them?
> When using that hashtable, it could be the superset, since not having
> that particular callback in there would not cause any lines of code
> in a prpl. The application would have to special-case the particular
> prpl, but that's the case anyways for special API like ad-hoc commands.

The prpl_info struct should be the common features and any protocol
specific features that can not be handled in better, more generic ways.
The hashtable, as already mentioned, comes with large type-safety losses
as well as requiring a number of places to do more complicated checks than
the simple (prpl_infp && prpl_info->callback) { prpl_info->callback() }
checks that now exist, including much protocol specific special casing
which generic mechanisms don't require.

<snip>

> The problem most of the time was that the libpurple devs didn't
> believe that a certain feature was desired to be implemented at all.
> In fact, the mere proposal of my project is in direct violation of
> the libpurple philosophy, which makes the whole thing very complicated.
> The reason is that my project aims to implement XMPP-specific
> features that are unique to the protocol, while libpurple aims to
> unify all protocols to the same feature set (probably rooted in the
> "treat all protocols like AIM" philosophy that was luckly overcome in
> libpurple, unlike in Adium). The action and request APIs can't solve
> all of this.
> Another basic issue of me personally is that I don't think that a
> cross platform networking library should define the user interface,
> but that's something I accepted in libpurple to be the root of the
> design concept.

That was the core problem exactly once, and was addressed immediately
thereafter and you were told to add it anyway. The fact that you have
persisted in thinking/claiming that you were attacked unreasonably and
prevented from progressing in your work is the problem I have been having
throughout most of this email thread.

libpurple tries to present a unified api to varying protocol features and
thus we don't much like the idea of adding protocol-specific api where it
isn't needed. This is a far cry from "unifying all protocols to the same
feature set".

You haven't given us clear examples of cases where the account action and
request apis have hindered your work yet, if you do we can discuss whether
they need to be improved, whether new generic mechanisms need to be added,
or whether something needs to be handled more explicitely (like via a
prpl_info member).

libpurple is not a "cross platform networking library" it is a "cross
platform multi-protocol IM client backend". There is a distinction to be
made there. Further, we have made numerous efforts specifically not to
specify a given UI for things, which is why we have taken so well when
Evan has told us that our use of the notify api caused Adium issues. The
fact that you have not been telling us where you are running into problems
means that we can't fix them.

<snip>

> andy

	-Etan