Nod... On new-ui-branch the addressbook will be using the ESource stuff which has UIDs though, so we should use the same approach Michael was suggesting there as well.
> We have a similar issue in the addressbook, where we're storing urls all > over that contain meta data that isn't updated properly on ldap server > changes. > > Chris > On Sun, 2003-09-21 at 18:57, Not Zed wrote: >> Not really fully formed, but it came into my head ... >> >> - Url's internally in evolution (mail) merely reference an account, >> plus a folder. >> - they do this via a unique id which gets assigned to an account when >> it is created. >> - any access to camel is then remapped from that uid to another, >> physically based one >> - the camel url's should lose metadata info, like filter on inbox, >> and that should be done vi >> persistent meta-data on the store object, et >> - the alternative would be to make camel url's work the same but then >> you'd need to have all the account info part of camel. >> - this alternative would have other advantages too, but its a lot of >> wor >> >> The filter code, the mailer, would use these internal url's, so that >> they would automagically update when the account changes, without >> having to track and change them all the time. >> >> Anyway i thought i'd mention it before i forgot it. >> >> Z >> > _______________________________________________ > evolution-hackers maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution-hackers -- Ettore _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
