Re: [Evolution-hackers] ESource shortcomings

[Hans Petter Jansson <hpj ximian com>]

On Mon, 2003-11-10 at 12:27, Ettore Perazzoli wrote:
> 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?

Well, an LDAP source has these properties (taken from
addressbook/gui/component/addressbook-storage.c):

     <contactserver>
           <name>LDAP Server</name>
	   <host>ldap.server.com</host>
	   <port>389</port>
	   <rootdn></rootdn>
	   <authmethod>simple</authmethod>
	   <emailaddr>toshok blubag com</emailaddr>
	   <limit>100</limit>
	   <rememberpass/>
     </contactserver>

Name, host and port should be covered by ESource proper (port can be
worked into the URI). However, rootdn, authmethod, emailaddr, limit and
rememberpass are not.

For webcal, I think I'll just need one property; the poll interval, in
seconds.


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

I think subclassing would be nicer, since it would specify which
properties are used, and provide easy type checking.


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

Ok, if sources are just going to be a list, this isn't really a problem.


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

So basically, I don't think we need the "move" folder op at all, and the
"copy" folder op only for local sources. Is that correct?


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

Will we support that sort of GConf fiddling?

--
Hans Petter