[Bug 26205] High-level API for ContactLists

[bugzilla-daemon at freedesktop.org]

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

--- Comment #29 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2011-06-09 03:11:41 PDT ---
I didn't look at the code, just the API.

I'm wondering if we shouldn't use a GPtrArray rather than a GList to return
the contacts. It offers at least those advantages:
- Easier memory management using the free func
- Can be reffed so user can easily keep it around
- Better memory usage

Actually, I'm starting to think we should consider using GPtrArray as our
'default' container when returning collections. The main advantages of GList
is to be more flexible to modifications, but in most case we don't care.


I'm not convinced that tp_{account,connection}_prepare_async() is the way to
go. Maybe a factory approach defining the features we want on every objects
would be better. We could have a TpFactory object implementing
TpClientChannelFactoryInterface and futures
TpClient{Account,Connection,Contact}FactoryInterface.

We'd pass this TpFactory to the most top lewel object (TpAccountManager) which
will pass it back to all the other objects created.

Isn't tp-qt4 doing something like that?

Is "guint n_contacts, TpContact * const *contacts," the best pattern for such
functions? In C, user will always have to create a GPtrArray a pass
array->len, array->data, so why not pass the GPtrArray directly?

This is different from the tp_proxy_prepare_async() case as there the array of
feature is always static so we can use G_N_ELEMENTS.

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