Or the other way around: let Empathy define what tp_account_manager_dup() will return: http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/log/?h=default-am

That does fix the TpContact creation/destruction issue.

But isn't this API a bit weird? User has to:
- Instantiate his factory
- Get an AM from it (tp_simple_client_factory_ensure_account_manager()).
- Call tp_account_manager_set_default() with this AM.

Just doing tp_account_manager_set_default_factory (factory); would be easier I think.

Actually isn't it weird to have tp_simple_client_factory_ensure_account_manager()? If we consider the AM as the "root" object of all the other objects (which is the case as we pass it to the TpSimple* constructors), why should we get it from the factory instead of passing the factory when creating the AM?

I admit this isn't really nice... What about this kind of API for apps wanting a custom factory:

main()
{
  TpSimpleClientFactory *factory = my_factory_new();
  TpAccountManager *manager;

  tp_account_manager_set_default_factory(factory);
  manager = tp_account_manager_dup();
  ...
  tp_account_manager_prepare_async(manager, ...);
}

so we can actually still use tp_account_manager_dup() like previously in the app (you can remove most of the empathy patch :/)

and tp_account_manager_dup() would do something like
{
  static TpAccountManager *manager = NULL;

  if (manager != NULL)
    return g_object_ref (manager);

  if (the_default_factory != NULL)
    manager = tp_simple_client_factory_ensure_account_manager (the_default_factory);
  else
    manager = tp_account_manager_new();

  return manager;
}


Does this looks nice to you?

(In reply to comment #3)
> I admit this isn't really nice... What about this kind of API for apps wanting
> a custom factory:
> 
> main()
> {
>   TpSimpleClientFactory *factory = my_factory_new();
>   TpAccountManager *manager;
> 
>   tp_account_manager_set_default_factory(factory);
>   manager = tp_account_manager_dup();
>   ...
>   tp_account_manager_prepare_async(manager, ...);
> }
> 
> so we can actually still use tp_account_manager_dup() like previously in the
> app (you can remove most of the empathy patch :/)
> 
> and tp_account_manager_dup() would do something like
> {
>   static TpAccountManager *manager = NULL;
> 
>   if (manager != NULL)
>     return g_object_ref (manager);
> 
>   if (the_default_factory != NULL)
>     manager = tp_simple_client_factory_ensure_account_manager
> (the_default_factory);
>   else
>     manager = tp_account_manager_new();
> 
>   return manager;
> }
> 
> 
> Does this looks nice to you?

This looks best to me. If the client cares about making its own factory, it can just set things up before preparing the FolksIndividualAggregator.

Xavier, has the latter code already been merged to tp-glib? It seems that way in master (though it doesn't do the ensure() step).

If tp-glib still needs changes, please add a tp-glib bug (and CC me) and list it in a new comment on this bug. Otherwise, please close this bug as NOTABUG.

everything is already in tp-glib 0.15.5 and used in empathy 3.1.5.1. Final API is sligthly different to what presented here:

factory = empathy_client_factory_new()
manager = tp_account_manager_new_with_factory(factory);
tp_account_manager_set_default(manager);

then tp_account_manager_dup() will give the one with empathy's factory. This is already done in empathy's main.

Closing this bug as it's not needed any more. As long as Folks use the default account manager we're good.