Proposals for 3.0.0 API changes

[Sadrul Habib Chowdhury]

* Will Thompson had this to say on [31 Dec 2007, 17:09:08 +0000]:
[snip]
> So when the request_action UiOp is called, Haze has no way to figure out
> what it's being asked without a massive lookup table looking something
> like:
> 
>     if (strcmp (primary, _("Accept chat invitation?"))
>     {
>         // * create a new muc
>         // * add self to local_pending
>         // * hook up accepting to the first callback (which we happen to
>         //   know from reading server.c is "accept").
>         // * hook up declining to the second.
>     }
>     else if (strcmp (primary, _("SSL Certificate Verification")))
>     {
>         ...
> 

What happens for an unhandled request?

[snip]
> First, some Telepathy background!  [Channels] are pretty much the
> fundamental objects in the API.  Multi-user chats are represented as
> [text channels] implementing the [Group interface].  When you are
> invited to a chat, a channel is created for that chat and you are added
> to the list of locally-pending members of that channel.  Moving yourself
> from the pending list to the current member list serves to accept the
> invitation, and removing yourself serves to decline it.

Confessions of a naive mind: I have never used any telepathy application.
I have never looked at any telepathy code. O:-) [for the uneducated,
that's an angelic smiley].

Now, what happens if you reject the invitation? Does the conversation
('channel') get closed? Would it be 'reasonable' to create the channel
and add yourself to the 'current member list' on creation if the
invitation is accepted (which I believe the callback would do anyway)?
Or are there other benifits in doing it the way you describe (e.g., does
the list of active members in the chat show up before you accept the
invitation? etc).

[snip]
> The point is that Haze doesn't know what
> question is being asked.

I guess what I am trying to figure out is: why is it necessary to
know what the question is, or specifically categorize every request? I
think the callback functions take care of whatever actions are required
to do something (e.g., the callback function for accepting a
chat-invite would end up creating the conversation and fetching the
list of users in the chat), in which case, the UI shouldn't, in theory,
need to care what the question is.

I see the benifit of handling certain requests differently. For example,
using 'request_authorization' (instead of 'request_action') for
authorizing a buddy allows finch to include the user-info in the request
dialog. I am sure there are other places where such special handling can
be useful. But having a different signal for every different operation
doesn't sound very appealing to me.

Sadrul