[Bug 29378] Implement Channel.Interface.Messages

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-10-04 09:07:45 PDT ---
This looks good to merge, but...

> +		G_IMPLEMENT_INTERFACE(TP_TYPE_SVC_CHANNEL_TYPE_TEXT, tp_message_mixin_text_iface_init);
> +		G_IMPLEMENT_INTERFACE (TP_TYPE_SVC_CHANNEL_INTERFACE_MESSAGES, tp_message_mixin_messages_iface_init);

In future please be consistent with whitespace on consecutive lines, at least
:-P

(In reply to comment #2)
> Yeah, emitting Sent just once is what you should do IMO

I disagree, actually: Sent should reflect what actually happened (in
particular, if you edit the message to get rid of CTCP or whatever, the Sent
signal should carry what you actually sent). Reversing this isn't a blocker for
this branch, though.

(In reply to comment #1)
> - I didn't generate a message-token as Gabble does. Should I?

No. Only generate a message-token if there's some actually-unique identifier on
the message.

(Note that message-token currently has impractical semantics in any case.)

> Furthermore, the mixin doesn't easily allow us to
> call tp_message_mixin_sent() multi times as the TpMessage is created by tp-glib
> and ownership is passed back to it once we call tp_message_mixin_sent() (so we
> can't re-use it for the other pieces).

The TpMessage API wasn't really designed with message splitting in mind: you'd
have to do something like:

* truncate the message body in the first fragment
* call tp_message_new() for the second and subsequent fragments, and copy in
the details

I think that'd work? I'll try to bear this in mind in any future work on
TpMessage.

(In reply to comment #2)
> Another issue is Sent should only be emitted when the last
> part of the message is actually cleared from the server connection send queue
> in IdleConnection (not when it's only queued there), so there should be some
> kind of callback mechanism for dequeued messages - or was there already, I
> can't recall...

"Sent" really means "submitted for sending" (if you delay until you're sure the
message has been sent, other UIs can't see it for a while). If the connection
is disconnected while the queue is still being drained, it'd be reasonable to
"receive" a Permanently_Failed delivery report for each queued message.

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