GObjectified Conversations

[Sadrul Habib Chowdhury]

* Mark Doliner had this to say on [21 Jul 2010, 22:30:03 -0700]:
> 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

If a plugin stores a PurpleConversation*, then it would need to clean up
when the conversation is destroyed anyway, and since in this transition,
a new chat is created, and the old IM is removed, thus the cleanup code
should kick in and it should not be a problem.

> > , which necessitates they all contain glue code to listen for
> > that signal and then replace the pointer everywhere

Creation of the new chat will trigger all the relevant signals, so the
plugin should be able to keep track of it if it wanted to, I think.

> > 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.

I am not sure I understand the 'always display as a muc' hint. Do you
mean the UI should always display a userlist, topic for an IM too?

I thought about the toggle-bit approach, and we would need to determine
a few things:

 * Should a conversation always maintain a userlist? When it's an IM,
   should it return NULL or a list with me and my friend in it? If my
   friend is included in the returned list, can it be inferred
   (mistakenly, of course) that he is still in this conversation (i.e.
   he has his window open)?

 * What happens with the logs when the conversation type is toggled?

 * What do we do if someone toggles the flag from MUC to IM?

 * With PurpleIM and PurpleMUC, it would be possible for a plugin to
   connect to signals of only one class if it so desires, and not have
   to check for the type of the conversation from the callbacks. This is
   clearly not a significant advantage, it seems kind of nice.

Right now, PurpleIM is simply an instantiable PurpleConversation.
PurpleMUC is a PurpleConversation, with some additional code (for
dealing with topic, adding/removing/renaming users etc.). So merging the
two involves (1) Making PurpleConversation instantiable (2)
s/muc/conversation/g, (3) Removing PurpleIM and PurpleMUC ... and that's
about it, i.e. fairly trivial.

I am not really dead set on either approach, yet, but like Mark, I have
a 'feeling', only that keeping that code related to MUC separate may
result in a cleaner code (... and of course, that tonight's gonna be a
good good night) ;)

Cheers.
Sadrul