| Summary: | Missing TpAccountChannelRequest high level API | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Guillaume Desmottes <guillaume.desmottes> |
| Component: | tp-glib | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | enhancement | ||
| Priority: | medium | Keywords: | patch |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://cgit.collabora.com/git/user/cassidy/telepathy-glib/log/?h=chan-request-75450 | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
(In reply to comment #0) > - FileTransfer.ContentHash(Type): > void tp_account_channel_request_set_file_transfer_hash > (TpAccountChannelRequest *self, TpFileHashType hash_type, const gchar *hash); If we're not planning to redesign it for 1.0. > - Setting None as TargetHandleType. We can either allows @identifier=NULL in > tp_account_channel_request_set_target_id() or maybe automatically set it > when requesting if no TargetHandleType has been provided? I think I'd prefer detecting whether a TargetHandleType has been provided. > void tp_account_channel_request_set_initial_invitees_ids > (TpAccountChannelRequest *self, const gchar * const * ids); "initial_invitee_ids" > and maybe a set_initial_invitees() taking a GPtrArray<TpContact> as well? Yes, I think this version would be good to have too. > + tp_asv_set_uint32 (self->priv->request,
> + g_strdup (TP_PROP_CHANNEL_TARGET_HANDLE_TYPE), TP_HANDLE_TYPE_NONE);
I'd rather use g_hash_table_insert instead of tp_asv_set_uint32 in situations where the memory allocation model doesn't match the one tp_asv_set_uint32 documents (namely "static keys, copied values"). This use of g_strdup() feels uncomfortably like "compensating errors".
Looks good otherwise.
(In reply to comment #3) > > + tp_asv_set_uint32 (self->priv->request, > > + g_strdup (TP_PROP_CHANNEL_TARGET_HANDLE_TYPE), TP_HANDLE_TYPE_NONE); > > I'd rather use g_hash_table_insert instead of tp_asv_set_uint32 in > situations where the memory allocation model doesn't match the one > tp_asv_set_uint32 documents (namely "static keys, copied values"). This use > of g_strdup() feels uncomfortably like "compensating errors". Fixed & merged to master. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Here are the high level API missing for Empathy: - FileTransfer.ContentHash(Type): void tp_account_channel_request_set_file_transfer_hash (TpAccountChannelRequest *self, TpFileHashType hash_type, const gchar *hash); - StreamTube: TpAccountChannelRequest * tp_account_channel_request_new_stream_tube ( TpAccount *account, const gchar *service, gint64 user_action_time); - DBusTube: TpAccountChannelRequest * tp_account_channel_request_new_dbus_tube ( TpAccount *account, const gchar *service_name, gint64 user_action_time); - SMS.SMSChannel: void tp_account_channel_request_set_sms_channel (TpAccountChannelRequest *self, gboolean is_sms_channel); - Setting None as TargetHandleType. We can either allows @identifier=NULL in tp_account_channel_request_set_target_id() or maybe automatically set it when requesting if no TargetHandleType has been provided? - Conference: void tp_account_channel_request_set_conference_initial_channels (TpAccountChannelRequest *self, const gchar * const * channels); void tp_account_channel_request_set_initial_invitees_ids (TpAccountChannelRequest *self, const gchar * const * ids); and maybe a set_initial_invitees() taking a GPtrArray<TpContact> as well?