Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote: I would expect that with CALOBJ_MOD_THIS it may remove only exact component, for uid + NULL-rid the master object (which implies also all generated instances) and keep all detached instances, Okay, then we agree on the desired semantic. though this operation doesn't seem to have much sense to me. It's certainly not a common operation, but the API should allow it nevertheless, because otherwise correct synchronization between a database where such an operation took place (for whatever reason) and EDS is hard. The problem is that each backend has its own implementation of such operation (also note that groupwise backend has no master object (it tells it in capabilities)) and for example file backend behaves with rid=NULL mod=CALOBJ_MOD_THIS the same like with mod=CALOBJ_MOD_ALL, thus it drops also detached instances. If a backend doesn't support the semantic, then there's not much that can be done. But the file backend should be able to to handle it, therefore I consider it a bug that it removes all instances in this case. I'll look into fixing this. I also wonder about the objects-removed signal in ECalView. If there are two events, one with RRULE and one with RECURRENCE-RULE, and both get removed, should there be two entries in objects-removed? I've no idea on this. I'm sorry. First things first ;-) Let me fix the removal, then look into this problem here. -- 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
[Evolution-hackers] EBookBackendSqliteDB comments
Hi Everyone, I spoke with chen on IRC this morning and got hinted at a preliminary implementation of EBookBackendSqliteDB sitting in -ews. Since there are some benefits of something something like this make it's way to a common place that could be used by -mapi as well, I thought I'd do a quick feasability review to see what problems there might be. Questions/commments/suggestions follow. Please let me know what you think! * No backend _get_contact/_get_contacts equivalent. Should be easily implemented. * _add_contact/_remove_contact should be renamed to _add_contacts/_remove_contacts to be consistant with other backend methods that take lists. * but also having a _add_contact/_remove_contact that takes just a uid (similar to other backends) would be useful * -mapi seems to use one cache per-profile-per-folder, but the sqlitedb backend takes these as calling parameters. Not really a problem and I think it may be reasons to have one cache db anyway, so this is just more of an observation. * _get/_set/_delete interfaces are needed for cache metadata (last modified, etc). * if folder metadata is going to be free-form, it could be better to have a key-value table ( folder_id_id int, key_name text, value text ) rather than arbitrarily numbered text/binary fields. * not sure of this one: given there may be multithreaded access to the db, do we need to provide any external big locks on reads/writes? maybe the built in sqlite stuff is sufficient. * not sure of this one: beyond the COMMIT statements, should there be something to periodically sync the db beyond the backend finalize method? Unsure with commit is sufficient to get consistant on-disk in case of crash, etc. * do we need a set_populated/is_populated equivalent? or maybe that could be solved in the cases it's needed wtih metadata. * do we need a set_time/get_time equivalent? or maybe that could be solved in the cases it's needed wtih metadata. @chen: I don't know how active you plan to be on this, but if you're looking to offload any work, I can pick up anything that results from the above if you like. Just let me know! 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
Re: [Evolution-hackers] (summarize ][) New 'eclient' branch in eds
Hi, I'm getting slightly lost what is left and what is under discussion, thus please let me summarize things here: On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote: First of all, +1 for rethinking the API. I'd like to suggest that besides modernizing the API we also take this opportunity to move more of EBook/ECal into a common core. It seems strange to me to have EClientSourceType defined in e-client.h and its main usage in other file (remember of compiler dependency issue), thus I suggest to keep e-client/e-book-client/e-cal-client as they are and rename e-client-authentication.h/.c (which resides in libedataserverui) to e-client-utils.h/.c and do common interfaces here. This is including also e_client_open_new() being defined here. This is for client-side code merging. We opened also a question of server-side merging (mainly merge factory and views into one base object and change only minimal parts (like dbus service names and backend types) in descendants. I can either postpone this, or do it before merging to master, though this is another big step. Talking of capabilities, I found their usefulness a bit limited because they a) cannot change during the life time of a client and b) they only report exists/doesn't exit. Here was suggested a common e_client_get_property_sync (EClient *client, const gchar *in_name, gchar **out_value, ...); function (with its async equivalent) (the e_client_get_backend_property_sync is better descriptive, less confusing with GObject properties, I guess, though it's quite long name). I'm fine with that, I can add it. Setting values should also be allowed. That gives us a way how a client can configure the storage to behave in certain ways. This can be per-database (tweak the actual on-disk storage) or per EClient (modify behavior as part of current session). This breaks abstraction, from my point of view. The client may not know/expect anything about backends, so any property setting from client side is not needed. You can ask for change tag, or last modified tag, but you should not be able to change it from client side in other than _add/_modify/_remove way. So here left basically three things, a) merging some API in utils, b) getting well-known properties, c) setting well-known properties and all are sorted out, I guess. Thinking of well-known properties, I would include other already used there too, like the cache-dir, cal-email-address, alarm-email-address, as these are just properties, only each has its own API, which is unnecessary. Is everyone fine with the above? (Note it's just my feeling about result of the discussions, which can be particularly wrong in any way.) Thanks and 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
Re: [Evolution-hackers] (summarize ][) New 'eclient' branch in eds
On Mi, 2011-05-04 at 14:37 +0200, Milan Crha wrote: Hi, I'm getting slightly lost what is left and what is under discussion, thus please let me summarize things here: On Thu, 2011-04-28 at 11:56 +0200, Patrick Ohly wrote: First of all, +1 for rethinking the API. I'd like to suggest that besides modernizing the API we also take this opportunity to move more of EBook/ECal into a common core. It seems strange to me to have EClientSourceType defined in e-client.h and its main usage in other file (remember of compiler dependency issue), thus I suggest to keep e-client/e-book-client/e-cal-client as they are and rename e-client-authentication.h/.c (which resides in libedataserverui) to e-client-utils.h/.c and do common interfaces here. This is including also e_client_open_new() being defined here. This is for client-side code merging. I still think that list and open databases are common operations and that having different libraries and code for contacts and calendar is a historic artifact. But let's not get hung up on that and move on without changing it. Talking of capabilities, I found their usefulness a bit limited because they a) cannot change during the life time of a client and b) they only report exists/doesn't exit. Here was suggested a common e_client_get_property_sync (EClient *client, const gchar *in_name, gchar **out_value, ...); function (with its async equivalent) (the e_client_get_backend_property_sync is better descriptive, less confusing with GObject properties, I guess, though it's quite long name). I'm fine with that, I can add it. Thanks. Setting values should also be allowed. That gives us a way how a client can configure the storage to behave in certain ways. This can be per-database (tweak the actual on-disk storage) or per EClient (modify behavior as part of current session). This breaks abstraction, from my point of view. The client may not know/expect anything about backends, That's not quite true in all cases. On an embedded system, a client might know exactly that it is going to be installed together with a specific backend and may want to influence that backend without having to maintain a non-upstream API for it. so any property setting from client side is not needed. Another situation would be a writable property that is supported by one or more backends. Writing in a backend which doesn't support should trigger an error, but in others it may make sense. For example, setting the color of a calendar is possible in CalDAV. A read/write property would make sense to expose that to clients. You can ask for change tag, or last modified tag, but you should not be able to change it from client side in other than _add/_modify/_remove way. change and last modified would be read-only. But other properties may be writable. Even if there are none predefined now, adding the API now is necessary to make it future-proof. -- 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] e_cal_remove_object_with_mod() + empty rid: semantic?
On Mi, 2011-05-04 at 09:41 +0200, Patrick Ohly wrote: On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote: I would expect that with CALOBJ_MOD_THIS it may remove only exact component, for uid + NULL-rid the master object (which implies also all generated instances) and keep all detached instances, Okay, then we agree on the desired semantic. I ran into another oddity: suppose there is a recurring event without exceptions and a detached recurrence gets added. The libecal API does not support undoing that operation. e_cal_remove_object_with_mod(rid=datetime, CALOBJ_MOD_THIS) will remove the recurrence but it will *also* add an EXDATE for that recurrence. So the calendar is not in the same state as it was before adding the detached recurrence. This behavior may make sense for a UI (remove this recurrence implies adding the EXDATE), but not for syncing. May I add a CALOBJ_MOD_REALLY_REALLY_REMOVE_THIS_ONLY mode? If a backend doesn't support the semantic, then there's not much that can be done. But the file backend should be able to to handle it, therefore I consider it a bug that it removes all instances in this case. I'll look into fixing this. I have a patch ready. Will continue to test and send when the rest also passes my tests. I also wonder about the objects-removed signal in ECalView. If there are two events, one with RRULE and one with RECURRENCE-RULE, and both get removed, should there be two entries in objects-removed? I've no idea on this. I'm sorry. First things first ;-) Let me fix the removal, then look into this problem here. ECalView is indeed odd. My initial understanding is that the file backend will never send information about removed detached recurrences, so rid is always empty. What I get instead when removing a detached recurrence is a master modified with EXDATE set. I suspect that the Evolution UI uses that to remove the corresponding detached recurrence. Does anyone know whether that is the case? If I introduce the CALOBJ_MOD_REALLY_REALLY_REMOVE_THIS_ONLY, then EXDATE won't be set and a real object-removed with rid set will be needed. -- 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
