[Bug 37112] Doesn't wait to get contact alias before adding event

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37112

--- Comment #6 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2011-05-12 08:03:51 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > What I mean is that at last resort, we should do the async prepare call on the
> > TpContact sender object, even for rooms. Otherwise there will still be cases
> > where it's not the alias that is being logged.
> 
> Ah I see. Yeah I'm aware this does not fix it in the MUC case, but it's better
> than before, and certainly no worse. It was just bugging me.

That's look good for 1:1 chat, but Why don't we also try sender-nickname for
chat rooms ?

> 
> In what case would priv->remote not be set, apart from the MUC case where it's
> obviously not set to something useful?

priv->remote is always set and perepared. The Observer will not return until
this one is prepared. I'm really focusing on the MUC case in my comment.

Originally we would keep a hash of all prepared contact, I've removed that hash
because we could not guaranty they where all prepared before the first message
comes in and I was assuming TpSignalledMessage was giving prepared TpAccount. I
think at the end, the only reliable solution for MUC would be:

if (chatroom)
  if (sender-nickname)
     create entity
   else
      _prepare_async()
else
  ...

Accepting that message may get miss-ordered if preparation does not return in
same order. Also, I still think this has to do with some bug in tp-glib, have
you spoke to Guillaume about that ?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.