Re: [Evolution-hackers] Regarding ESource and ESourceExtension

[Tristan Van Berkom <tristanvb openismus com>]

On 10/08/2012 08:55 PM, Matthew Barnes wrote:
> On Mon, 2012-10-08 at 18:40 +0900, Tristan Van Berkom wrote:
> > Is it intended that the frontend must know what extensions are
> > supported by a given backend ?
>
> What extensions are you worried about, specifically?  And what's the use
> case for configuring them by hand?

Hi again Matthew,
   More specifically, I was under the impression that the
ESourceExtensions were (at least partially) for the purpose of,
well, extending the work flow and configurations provided by
given backends.

For instance, currently the address book backends report "capabilities"
and "supported fields" via the EBookBackend properties, providing a
way for frontends to see what is possible to do with the given
backends that they are using (or predict how it will react when
asked to do something specific).

It seems rather tempting (and clean) to go with the extensions as
a method of adding custom configuration to some, but not all backends.

One simplistic example of the usefulness in this would be, you could
potentially tell the local addressbook backend that it should transform
incoming photo contact fields into local uris, or prefer not to, and
even specify a local directory where the sysadmin/user might chose the
photos should be stored, however this "extension" would only make sense
for the local addressbook.

Of course it would be nice if, additionally, the tooling around this
would be able to automatically detect which extension was available
on which backend. For the simplistic example above, it would enable
a hypothetical addressbook interaction tool, at creation time, to
decide whether to display a file selector to decide where photos
should be stored on disk, but only if "Local Address Book" was
selected as the storage type of the addressbook being created.

Best Regards,
         -Tristan