GObjectified Conversations

[Mark Doliner]

On Wed, Jul 21, 2010 at 8:38 PM, Paul Aurich <paul at darkrain42.org> wrote:
> On 2010-07-21 20:28, Sadrul Habib Chowdhury wrote:
>> * Richard Laager had this to say on [21 Jul 2010, 21:59:35 -0500]:
>>> It seems to me that this complicates the situation with MSN, where you
>>> can add a third user to a one-on-one conversation at any time. Assuming
>>> this is still possible with the MSN protocol, how are we going to handle
>>> that transition?
>>>
>>> If we can avoid this distinction in libpurple, we can leave the UI
>>> decisions to the UI. On the flip side, though, I don't think we want the
>>> UI to represent an IRC/Jabber/etc. room with two users the same way it
>>> represents a one-on-one AIM conversation.
>>
>> This is one of the primary reasons I think we should maintain the
>> distinction between IM and MUC. A few of us discussed this a bit in
>> devel at cpi a couple of days back, and a few of us agreed that the UI will
>> need some help from libpurple to decide whether a conversation with
>> one/two users is a MUC or an IM.
>
> I personally think having a boolean flag is sufficient to give this help
> to the UI, and is my preference over distinct types.
>
> MSN (and XMPP -- XEP-0045 offers functionality somewhat akin to what MSN
> does) would twiddle the flag, which presumably emits a signal, at which
> point the UI adds a chat sidebar and does whatever else to turn a 1:1
> into a MUC.
>
>>> So, perhaps we'll just need a defined way to switch between the two
>>> types? Even so, do we need different objects, or just a bit that flags
>>> what type it is currently?
>>
>> We can do that even now, since we maintain the message history in a
>> PurpleConversation. So we would do something like this:
>>
>>   PurpleConversation *convert_im_into_muc(PurpleConversation *im)
>>   {
>>     PurpleConversation *muc =
>>       purple_conversation_new(TYPE_CHAT, im->account, im->name);
>>     GList *iter;
>>     for (iter = im->message_history; iter; iter = iter->next) {
>>         PurpleConvMessage *msg = iter->data;
>>         add_message_to_history(muc,
>>                 msg->who, msg->alias,
>>                 msg->what, msg->flags, msg->when);
>>     }
>>     return muc;
>>   }
>>
>> [treat this as pseudocode]
>
> I'm honestly not keen on this.  I think that this method of upgrading
> would be problematic, in particular because any code/plugins that
> hang(s) on to a PurpleConversation* would have to know that it had been
> replaced, which necessitates they all contain glue code to listen for
> that signal and then replace the pointer everywhere, when it would be
> much easier to just keep the same object around with a twiddled bit
> (then only things that need to know about a 1:1->MUC change have to
> listen for a signal/check the bit as needed). :)

I totally agree with Paul on this.  Aside from his well articulated
points, I have "a feeling" that having something simple like an
"always display as a multi-user chat" hint is more natural and will
result in cleaner code.

--Mark