[Bug 27175] Make TpMessage usable in clients

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-10-14 07:15:36 PDT ---
> +      if (self->reffed_handles[i] != NULL)
> +        {
> +          tp_handle_set_destroy (self->reffed_handles[i]);
> +          self->reffed_handles[i] = NULL;
> +        }

tp_clear_pointer? :-)

Looks good so far apart from that.

(In reply to comment #2)
> > - make client-side received-message objects read-only? (we still need the set
> > methods to work client-side while sending a message, though)
> 
> Should we use the same object or a new one sharing a common sub-class?

A common superclass is probably the right answer. I'd like TpMessage to be the
name of the superclass if we can get away with it.

> > - make it use TpVariantMap internally (Bug #30423) and use the dbus-glib escape
> > hatch to convert to/from dbus-glib GValues when necessary?
> 
> I guess we need both variants, right?

I think we can have one as the canonical representation, and construct the
other on-demand. tp_message_peek() is the only thing that strictly requires the
dbus-glib representation, until we send the message.

> > - add a tp_message_copy?
> 
> Not sure that's needed, we can just ref the object.

It's mutable, though, so we want to be able to deep-copy it too. Perhaps
tp_message_deep_copy()?

> > - handle refcounting works differently in the CM and in a client
> 
> Yeah, which make me think it could be cleaner to have 2 objects.

It's a sad time that the TpMessage name is already in use...

> > - also deal with the case of a serialized/deserialized message (use GVariant),
> > in which handles are no longer meaningful, but string IDs are still useful?
> 
> Humm, I'm not sure to understand. Can you ellaborate?

TpMessage is essentially an aa{sv} plus a set of reffed handles.

There are three uses for a TpMessage:

- In a CM. We can ref handles of any type, synchronously. Handle fields like
parts[0]['message-sender'] are essential.

- In a client dealing with a live Channel. Handles are reffed for as long as
the message is unacknowledged, so we need to make sure we have a ref before
acknowledging. telepathy-glib only makes this easy for contact handles.
TpTextChannel can't do this generically, because it doesn't know which uint32
keys might be a handle, and if so, which type they are.

- Serialize the aa{sv}, put it in telepathy-logger, deserialize it and use it
again later. Handle fields like parts[0]['message-sender'] are completely
meaningless, but if we had a message-sender-id field, that'd still be useful.

In Tpl the sender ought to be denormalized into a separate database column
anyway, but we'd have the same problem with any extension field that was a
handle.

Perhaps the solution is to say that message-sender is the only handle that will
ever appear in a Message_Part, and deprecate tp_message_set_handle() in favour
of a new tp_cm_message_set_sender()?

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