[Bug 27175] Make TpMessage usable in clients

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2010-10-15 01:57:17 PDT ---
(In reply to comment #4)
> > +      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.

fixed.



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

Most of the tp_message_* API makes sense as a base class except:
tp_message_new() : as it takes a TpBaseConnection
tp_message_take_message() ? not sure.

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

Right, so we can add a variant of _peek() using variants.

> > > - 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()?

Ok. I think _copy() is clear enough.

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

What should we do?

Make TpMessage the base class and have TpCMMessage (or TpSvcMessage?) and
TpClientMessage (or TpCliMessage?) ? Then we have to document than the methods
above can only be used with CM messages but are named that way for historical
reason.

Or we can add TpBaseMessage and keep TpMessage as it but we'll have to
duplicate most of the API of tp_message_* in tp_base_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.