Re: [Evolution-hackers] ESource shortcomings

[Ettore Perazzoli <ettore ximian com>]

Hi Hans Petter,

On Mon, 2003-11-10 at 02:29, Hans Petter Jansson wrote:
> - Some sources, like LDAP, and to a lesser extent, webcal, require
>   a additional properties to be specified. ESource doesn't
>   seem to facilitate storage of these properties, and adding those
>   fields to ESource itself would be gross. I can think of two
>   solutions: let ESource support arbitrary named properties, or
>   write ESource subclasses.

I think it's easier to just have arbitrary named properties.  What
properties are you thinking about?

(Although, maybe something like ELDAPSource vs. EWebCalSource would make
for a nicer, easier to understand API?)

> - The relative URI isn't of much use in sources we do not control.
>   I.e. you may have an ESourceGroup whose only common denominator
>   is the protocol (i.e. webcal, LDAP), and the child source URIs
>   are in effect absolute. Moving the child sources around does not
>   change their URIs.

Yeah, but then, what do you propose?  It's not *necessary* for the
parent URI to be anything in particular.  Even "ldap://"; will do.

> I'm also wondering how we'll support folder configurations like the ones
> we had in 1.4 - with arbitrary hierarchical ordering of folders - which
> seems to imply ESources with both data and children. I don't know if we
> will, but if we don't, "move folder" becomes a very limited operation,
> and might not make a lot of sense.

No, ESources are just supposed to be lists.

> Oh, another thing :) Will the user be able to create arbitrary top-level
> ESourceGroups, and if so, how will the UI for that look, roughly?

Not unless she fiddles with GConf by hand.  The groups are pretty much
supposed to be defined by the app, which should use them to group
objects sensibly.

-- Ettore