Re: [Evolution-hackers] (summarize ][) New 'eclient' branch in eds
On Mon, 2011-05-09 at 17:49 +0200, Milan Crha wrote: > It's just because of (so called) consistency. With merging common error > codes into E_CLIENT_ERROR_ "namespace" I realized that checking for > particular errors will not be that easy as is now, because one might > have two switches, one for domain E_CLIENT_ERROR and the other for > E_CAL/BOOK_ERROR. Not a big deal, but still. If you're using a switch statement to check for specific GErrors then you're doing it wrong. You should be using g_error_matches() for each case, so it doesn't matter if all the error codes are in the same domain or they're all in different domains. I'd like to get rid of the redundancy. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] (summarize ][) New 'eclient' branch in eds
On Mon, 2011-05-09 at 17:41 +0200, Patrick Ohly wrote: > Why duplicate the LOADED/ONLINE/READONLY/CACHE_DIR/CAPABILITIES > properties? They could be defined as common E_CLIENT_BACKEND_ > properties. It's just because of (so called) consistency. With merging common error codes into E_CLIENT_ERROR_ "namespace" I realized that checking for particular errors will not be that easy as is now, because one might have two switches, one for domain E_CLIENT_ERROR and the other for E_CAL/BOOK_ERROR. Not a big deal, but still. And even it is not the same thing, I didn't want to have some properties in CLIENT_BACKEND_ "namespace" and some in each respective, having to hunt in documentation/header files for a complete list of properties. Maybe doesn't matter at all? It's easy to change it. 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
Re: [Evolution-hackers] (summarize ][) New 'eclient' branch in eds
On Mo, 2011-05-09 at 17:00 +0200, Milan Crha wrote: > On Wed, 2011-05-04 at 14:37 +0200, Milan Crha wrote: > > So here left basically three things, > >a) merging some API in utils, > >b) getting well-known properties, > >c) setting well-known properties > > Hi, > I just did a commit into the eclient branch with a fix for b) and c). > There is a little change, I named those functions: >e_client_get_backend_property_sync >e_client_set_backend_property_sync > with their async versions too. > > Well-known properties are: > * for a book: > BOOK_BACKEND_PROPERTY_LOADED > BOOK_BACKEND_PROPERTY_ONLINE > BOOK_BACKEND_PROPERTY_READONLY > BOOK_BACKEND_PROPERTY_CACHE_DIR > BOOK_BACKEND_PROPERTY_CAPABILITIES > BOOK_BACKEND_PROPERTY_REQUIRED_FIELDS > BOOK_BACKEND_PROPERTY_SUPPORTED_FIELDS > BOOK_BACKEND_PROPERTY_SUPPORTED_AUTH_METHODS > >* for a calendar: > CAL_BACKEND_PROPERTY_LOADED > CAL_BACKEND_PROPERTY_ONLINE > CAL_BACKEND_PROPERTY_READONLY > CAL_BACKEND_PROPERTY_CACHE_DIR > CAL_BACKEND_PROPERTY_CAPABILITIES > CAL_BACKEND_PROPERTY_CAL_EMAIL_ADDRESS > CAL_BACKEND_PROPERTY_ALARM_EMAIL_ADDRESS > CAL_BACKEND_PROPERTY_DEFAULT_OBJECT Why duplicate the LOADED/ONLINE/READONLY/CACHE_DIR/CAPABILITIES properties? They could be defined as common E_CLIENT_BACKEND_ properties. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] (summarize ][) New 'eclient' branch in eds
On Wed, 2011-05-04 at 14:37 +0200, Milan Crha wrote: > So here left basically three things, >a) merging some API in utils, >b) getting well-known properties, >c) setting well-known properties Hi, I just did a commit into the eclient branch with a fix for b) and c). There is a little change, I named those functions: e_client_get_backend_property_sync e_client_set_backend_property_sync with their async versions too. Well-known properties are: * for a book: BOOK_BACKEND_PROPERTY_LOADED BOOK_BACKEND_PROPERTY_ONLINE BOOK_BACKEND_PROPERTY_READONLY BOOK_BACKEND_PROPERTY_CACHE_DIR BOOK_BACKEND_PROPERTY_CAPABILITIES BOOK_BACKEND_PROPERTY_REQUIRED_FIELDS BOOK_BACKEND_PROPERTY_SUPPORTED_FIELDS BOOK_BACKEND_PROPERTY_SUPPORTED_AUTH_METHODS * for a calendar: CAL_BACKEND_PROPERTY_LOADED CAL_BACKEND_PROPERTY_ONLINE CAL_BACKEND_PROPERTY_READONLY CAL_BACKEND_PROPERTY_CACHE_DIR CAL_BACKEND_PROPERTY_CAPABILITIES CAL_BACKEND_PROPERTY_CAL_EMAIL_ADDRESS CAL_BACKEND_PROPERTY_ALARM_EMAIL_ADDRESS CAL_BACKEND_PROPERTY_DEFAULT_OBJECT I dropped API functions for those properties, except of CAL_BACKEND_PROPERTY_DEFAULT_OBJECT, which left there because the API returned icalcomponent, not a string. As a side-effect the the get_capabilities EBookClient/ECalClient functions have been removed. Default implementation for getter on EBook/CalBackend takes care of common properties and returns a Not Supported error when it is asked for a property it doesn't know anything about. The setter's default implementation returns the Not Supported error always. I hope it is something close to that what you expected. Bye, Milan P.S.: merging to utils is not done yet ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EBookBackendSqliteDB comments
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 unsubscr
Re: [Evolution-hackers] EBookBackendSqliteDB comments
On Fri, 2011-05-06 at 10:01 +0200, sean finney wrote:
> Hi Milan,
>
> On Fri, May 06, 2011 at 08:56:10AM +0200, Milan Crha wrote:
> > > 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 :)
http://git.gnome.org/browse/evolution-ews/tree/src/addressbook/e-book-backend-sqlitedb.h
has the API's. Meta-data apis is work-in-progress.
> >
> > 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 think we should stop and consider two different motivations for this
> API. (1) Local addressbook (2) Local cache of remote addressbook. For
> case (1), I agree that having the items split out could be useful and
> a good safeguard against any db corruption (though my experience thusfar
> with sqlite is fairly positive).
>
> For case (2), I would say if there's a problem with the file just nuke
> it and reload it from the remote store. Since you can guarantee that
> you can get a "working copy" of the info, you can then rely on the existing
> UI (or sqlite, or the remote service, or whatever), for exporting the
> contacts. It is a *cache* after all :)
>
> So for something like GAL (or any cached-from-remote addressbooks),
> I think it makes a lot of sense to *not* split out the contacts, at
> least as long as performance doesn't suffer by having more items in
> the sqlitedb file.
I wanted to check the performance on the address-books which has huge
data in them between the two methods and choose the best which suits.
If it turns out that there is a big difference between the two, i would
document that and allow a choice for the backends to choose how they
want to store the data.
>
> > c) folders.db files tend to grow "indefinitely". That's another point
> > why I do not like "one file per account".
>
> I'd like to clarify a detail of the API from having looked over it wrt
> evo-mapi: it's designed so that it can be used "one file per account", by
> creating a single db file and specifying the "folder" as an API parameter
> in all calls.
>
> But this means you could always create multiple db instances at different
> file locations, one per folder, and just use a junk "FOLDER" (or similar)
> name for the folder. Having looked over the current evo-mapi code, I
> think you'd want to do soemthign like that.
>
> Of course if you think that there should *never* be a cas where it's used
> one db per account, then rethinking the API would make sense, but otherwise
> nothing lost by keeping it, it gives you a way to do both.
I have made it configurable. So the clients can choose to save all the
address-books in one db or provide different paths so that they would be
stored in different db files.
>
> > 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
>
> And that should be possible, see above.
>
> > 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.
>
> The underlying db should deal with stuff like UID clashes, agreed. I
> think the current API does so, though I'm not convinced it's the best
> way. Currently, you have:
>
> const gchar *stmt = "CREATE TABLE IF NOT EXISTS folders \
>( folder_id TEXT PRIMARY KEY,
> \
> folder_name TEXT,
> \
> sync_data TEXT,
> \
> bdata1 TEXT, bdata2 TEXT,
> \
> bdata3 TEXT)";
>
> stmt = sqlite3_mprintf ("CREATE TABLE IF NOT EXISTS %Q \
> ( uid TEXT PRIMARY KEY, \
> nickname TEXT, full_name TEXT, \
> given_name TEXT, family_name TEXT, \
> email_1 TEXT, email_2 TEXT, \
> email_3 TEXT, email_4 TEXT, \
> vcard TEXT)", folderid);
>
> which AIUI means a table named after every folder. Therefore the UID's
> are already internally partitioned and will not conflict. WRT normalizing
> the database, I would suggest something more like:
>
> const gchar *stmt = "CREAT
Re: [Evolution-hackers] EBookBackendSqliteDB comments
On Thu, 2011-05-05 at 14:49 +0200, sean finney wrote: > On Thu, May 05, 2011 at 12:23:01PM +0530, Chenthill wrote: > > > Be sure that parsing bdata is a pain, and always will, > > > especially when you already are in a database world, where are tables > > > and relations between them pretty common and nature. > > This is the reason I was thinking whether it would be good idea to have > > a abstract API to store extended (apart from sync_data, populated > > columns etc.) key-value pairs if the backend needs. This can form the > > xml and store it as bdata. Now the bdata would not be exposed to the > > callers. Is there any other better way to do this ? > > Forgive the rusty SQL, but assuming you have a single db with > multiple folders in it, soemthing like: > > create table folder_kvdata ( > folder_id_id int foreign key references folders(folder_id), > keyname text, > keyval text > ); > > ? With this it would be pretty trivial to fetch single values > as well as enumerate/update/delete all keys/values for a folder. > If the caller needed something more complicated than a single value, > an xml object or whatever else could be embedded on an as-needed basis. This is far better. Would get it done this way. - Chenthill. > > > > If I recall correctly then "populated" and "last_modified" were also > > > stored as keys in the background, but backend could drop them > > > accidentally, when accessing through keys "directly". It sometimes can > > > be considered a benefit, but it usually isn't. If I have specialized API > > > to access these keys, then I should use it exclusively. I think. > > For the commonly used keys such as the above we would have specialized > > API's and they would be having separate columns on a per-folder basis. > > yeah, I think it would be a good idea to claerly break them out from > the "general" k/v pairs, to avoid conflicts and special-casing any code. > > > > 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 :) > > W.r.t. a performance standpoint, I will be testing against a Global > Address List of somewhere around 60k entries, so that should give a > pretty good idea :) > > I think Milan also had concerns with regards to "stability/fragility", > with corrupting databases, etc. But I don't think that the "split out" > option is immune from these types of problems as well (and there may be > even further problems, since we would be home-rolling that solution as > opposed to relying on a well tested API/DB). > > > sean ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
