On Fri, 2011-05-06 at 08:56 +0200, Milan Crha wrote: > (Please do not reply to me, reply to the list, I read the list and I > prefer to Ctrl+L while your message avoids this feature for me. Thanks > for your understanding.) > > On Thu, 2011-05-05 at 12:23 +0530, Chenthill wrote: > > > you scary me. Could you repeat where is written information about a > > > design you chose for this, how it correlates with actual backend > > > cache(s) (we do not want to loose functionality here) and maybe why done > > > so? > > Well, I have not started on the meta-data storage yet :) Just have a > > table for it. There is no specific design for it. > > Hi, > my above question wasn't only about meta-data, it was a general question > "what are you doing and how are you doing that". Without that answered > it's just confusing. I will appreciate something like "we have now these > options, storing these values... and we will have it changed to this > which will be doing this and this". I believe you have it somewhere > done, I only didn't notice where. I'm sorry for that. > > For example, you mentioned once that there should be benefical to use > only summary columns to be returned for some cases, like autocomplete, > which doesn't require fully populated contacts. It makes sense from my > point of view and I will add > > e_book_client_view_set_restriction_fields_sync (..., const GSList > *fields_to_fetch, ...) > > which will set list of field names to be fetched only on a view. Yup that is possible. This would also need another column mentioning whether the contact is fully cached or not, will add the same.
> > Another thing, I do not understand much why we are talking about XML > here. Why to combine two approaches when you have one already, the > database? Though of course, if it's just meant that the key-value pair > can store (the value part) just anything the caller wants, then yes, I'm > all fine with it. Its just about the key-value pairs. > > > I recall us chatting about this on IRC or somewhere one day and one > > > point was that the contacts will not be stored in a binary form, but > > > rather as separate files. What Sean wrote earlier sounds like you > > > changed your mind in this point. I do not think it's a good idea, see > > > how often the sqlite folders.db file in camel is broken, and users are > > > adviced to delete it. Will they loose all their contacts in such > > > situation? > > As I already said seanus on irc, I will be evaluating the performance > > between having vcards as files Vs having it in db and then choose the > > one which would be best. So the code for both will be there and we can > > choose between them over after testing. I was also thinking of providing > > it as an option for the backends to choose once i complete the testing.. > > So what we discussed stays the same :) > > This is not only about performance, my main concerns are these: > a) if something fails with db file, user's data are safe > b) users can take their contacts anytime and import them on another > machine, in case of hard disk crash, partial backup or anything like > that I hope seanus's reply addresses this. For remote address-book's if db is corrupt, the local keys like 'last-modified' time would be lost, so we would anyways cache all the data again even if the vcards might be there to ensure that we are in sync with the server. I will check the performance impact and if there is no big difference, will go for storing them as separate files. If there is a considerable difference, will provide options for both. > c) folders.db files tend to grow "indefinitely". That's another point > why I do not like "one file per account". [i missed say this in the previous reply to seanus, so just adding it here] My idea here was to make it configurable, so that all personal address-books can use one file and a relatively bigger address-book like GAL can use a separate db file. http://git.gnome.org/browse/evolution-ews/tree/src/addressbook/e-book-backend-sqlitedb.h Rest I hope I have answered in another reply to seanus. - Chenthill. > > An example: my evo-mapi account has 4 addressbooks (one is GAL). I would > really prefer to have them separated, not in one large file. Not talking > about possible (even unlikely) UID clashes between separate > addressbooks. Will it also mean that each local addressbook will be > stored in one large db? Please do not do that. > > As I said in the very beginning, I still do not see what you are doing > and how; it might be a good time to open the code and check that out :) > Bye, > Milan > > _______________________________________________ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers