[Evolution-hackers] ESource shortcomings



There are two things about ESource as it stands now that strike me as
not ideal:

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

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

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.

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?

Thoughts?

--
Hans Petter




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]