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 _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
