Re: [Evolution-hackers] Regarding API breakage and lost test cases

[Tristan Van Berkom <tristanvb openismus com>]

On 02/01/2013 05:08 AM, Matthew Barnes wrote:
> On Thu, 2013-01-31 at 20:47 +0100, Milan Crha wrote:
> > I vote for Tristan's 2), basically because it's the right approach in
> > client-server architecture, also used in evo-mapi (and maybe in evo-ews,
> > I do not know). Basically, if client doesn't have anything it was asked
> > for, then it doesn't mean that the server doesn't have it too.
>
> Having e_source_registry_ref_source() make secret blocking D-Bus calls
> is out of the question.  I just spent a good deal of effort eradicating
> all that from our libebook/libecal APIs.

It does not have to be secret, nor does it have to block.

e_source_registry_ref_source() could be deprecated for a more
complete API offering a convenience blocking _sync() variant,
if the source happens to be readily available, then the async
callback could complete immediately.

I have to agree a bit that doing it your third proposed
way has a few problems:

   a.) You will have to keep that complexity in ESourceRegistry
       to virtually postpone completion of the
       create_source() D-Bus method.

   b.) It might not be sufficient, in any case where you have
       backends communicating sideways (i.e. amongst each other).

       I.e. When creating an addressbook, and then handing off
       that newly created ESource UID to an existing Calendar
       with the "contacts" backend, we still dont know if that
       specific calendar process has been notified of the new
       ESource in it's local ESourceRegistry by the time we've
       explicitly registered the new ESource UID with that
       calendar.

Note, I realize the calendar contacts backend API doesn't
work exactly like this (i.e. instead, every single contacts
backend registers every single addressbook which specified
"include-me = TRUE" in the ESourceContacts extension),
but I wonder if that lack of specificity in the API is due
to this exact flaw which we're currently discussing.

Anyway, take your time and give it some thought, I realize
you're busy with your D-Bus codegen port which is going to
greatly simplify things as well.

Best Regards,
            -Tristan