Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data
On Wed, 2010-07-14 at 17:37 +0530, chen wrote: > ECalComponent - This holds the calendar event's data in Ical format. It > wraps Icalcomponent, but has not completely wrapped the same. So both > are used at places. ECalComponent is better to use as its a Gobject. > ECalBackendSync - Abstract class from which you would need to subclass > kolab backend. (http://live.gnome.org/Evolution/CalendarStore) Hi, you said you want everything async, thus I agree with Ross, do not use ECal/BookBackendSync, but rather ECal/BookBackend parents, and do everything yourself (similar actions like ECal/BookBackendSync does, only fully asynchronously). I plan to rewrite evolution-mapi backends to be fully asynchronous. I'm not sure how it'll go and when I get to it, but maybe you would get inspired, if it'll be as I hope it. > ... > http://www.go-evolution.org/EDS_Architecture - I find that its not there > in lgo, will need to be migrated. It's there, I'm not sure why it isn't shown up for you: http://live.gnome.org/Evolution/EDS_Architecture 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] [evolution-kolab] Datastructures for calendar data
On Wed, 2010-07-14 at 20:14 +0530, chen wrote: > > Though only subclass this if you can't handle the async nature of the > > ECalBackend API yourself. Whether you subclass ECalBackend or > > ECalBackenSync is a choice made by how the backend will be implemented. > Is this used by any backends or will be used ? I was just having this > question while reading through the go-evolution.org link. > ECalBackendSYnc adds the notification to the clients for the sync calls > made by the clients through libecal, which anyways cant be ignored isn > it ? So usage of ECalBackend functions for sync calls such as, > e_cal_backend_create_object, get_object, get_object_list etc. just adds > extra work of notifying the clients using e_data_cal_notify*. > > If the answer is, they are not used, better to mark them as deprecated > and cleanup this area. ECalBackend can then just be used for Async apis > like, > e_cal_backend_notify_object_(added, modified, removed) and future > free/busy async apis etc. But if your backend can make async calls (say you implement it using GIO) then you can drop the BackendSync layer and notify yourself. One of my plans was to move the "each operation in a thread" logic into E*BackendSync because asynchronous backends obviously don't need to be in a thread. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ 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] [evolution-kolab] Datastructures for calendar data
Hi there, On Wednesday 14 July 2010 Ross Burton wrote: > On Wed, 2010-07-14 at 20:14 +0530, chen wrote: > > > Though only subclass this if you can't handle the async nature of the > > > ECalBackend API yourself. Whether you subclass ECalBackend or > > > ECalBackenSync is a choice made by how the backend will be implemented. > > Is this used by any backends or will be used ? I was just having this > > question while reading through the go-evolution.org link. > > ECalBackendSYnc adds the notification to the clients for the sync calls > > made by the clients through libecal, which anyways cant be ignored isn > > it ? So usage of ECalBackend functions for sync calls such as, > > e_cal_backend_create_object, get_object, get_object_list etc. just adds > > extra work of notifying the clients using e_data_cal_notify*. > > If the answer is, they are not used, better to mark them as deprecated > > and cleanup this area. ECalBackend can then just be used for Async apis > > like, > > e_cal_backend_notify_object_(added, modified, removed) and future > > free/busy async apis etc. > But if your backend can make async calls (say you implement it using > GIO) then you can drop the BackendSync layer and notify yourself. One > of my plans was to move the "each operation in a thread" logic into > E*BackendSync because asynchronous backends obviously don't need to be > in a thread. Thanks for all input. This week, we should finish our initial planning phase and start implementing a few things. We'll have more time then to read code than it was the case before. I hope we'll have some spare time to organize all information into one document so it can serve as a reference. Most likely, it will be a copy&paste-thing gathering the answers we got here. I'll post a link once we have something ready. Best regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ 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] [evolution-kolab] Datastructures for calendar data
On Wed, 2010-07-14 at 13:23 +0100, Ross Burton wrote: > On Wed, 2010-07-14 at 17:37 +0530, chen wrote: > > ECalBackendSync - Abstract class from which you would need to subclass > > kolab backend. (http://live.gnome.org/Evolution/CalendarStore) > > Though only subclass this if you can't handle the async nature of the > ECalBackend API yourself. Whether you subclass ECalBackend or > ECalBackenSync is a choice made by how the backend will be implemented. Is this used by any backends or will be used ? I was just having this question while reading through the go-evolution.org link. ECalBackendSYnc adds the notification to the clients for the sync calls made by the clients through libecal, which anyways cant be ignored isn it ? So usage of ECalBackend functions for sync calls such as, e_cal_backend_create_object, get_object, get_object_list etc. just adds extra work of notifying the clients using e_data_cal_notify*. If the answer is, they are not used, better to mark them as deprecated and cleanup this area. ECalBackend can then just be used for Async apis like, e_cal_backend_notify_object_(added, modified, removed) and future free/busy async apis etc. - Chenthill. > > Ross ___ 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] [evolution-kolab] Datastructures for calendar data
On Wed, 2010-07-14 at 17:37 +0530, chen wrote: > ECalBackendSync - Abstract class from which you would need to subclass > kolab backend. (http://live.gnome.org/Evolution/CalendarStore) Though only subclass this if you can't handle the async nature of the ECalBackend API yourself. Whether you subclass ECalBackend or ECalBackenSync is a choice made by how the backend will be implemented. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ 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] [evolution-kolab] Datastructures for calendar data
On Tue, 2010-07-13 at 15:36 +0200, Christian Hilberg wrote: > Hi again, > > no ideas? Anything? I will summarize some of the DataStructures here which you will be using in the backend, ECalComponent - This holds the calendar event's data in Ical format. It wraps Icalcomponent, but has not completely wrapped the same. So both are used at places. ECalComponent is better to use as its a Gobject. ECalBackendSync - Abstract class from which you would need to subclass kolab backend. (http://live.gnome.org/Evolution/CalendarStore) ECalBackend - Use api's from this class to notify the clients on event changes (_remove, _added, _modified). ECalBackendStore - Abstract class for the calendar cache. ECalBackendFileStore - file is derived class of the above class and used for storing calendar contents. ECalBackendFactory - Abstract class for the factory which your backend needs to subclass. e-cal-utils.h - should have some utility functions. http://www.go-evolution.org/EDS_Architecture - I find that its not there in lgo, will need to be migrated. Having this as pointers and looking through existing backend implementation would give you a better idea. - Chenthill. > > Best regards, > > Christian > > ___ > 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
Re: [Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - July 14 - 3:30 PM UTC
On Tue, 2010-07-13 at 11:34 +0530, Srinivasa Ragavan wrote: > On Tue, Jul 13, 2010 at 11:07 AM, chen wrote: > > Hi all, > > Our this month's community meeting happens on July 14th. This would > > be the community meeting before GUADEC 2011!! > > Isn't this supposed to be GUADEC 2010? ;-) it is 2010, good observation :) - Chenthill. > > -Srini. > > > > Post any queries to the list today if you want them to be answered in > > the community meeting. Gives some thinking time for all the people for a > > fruitful discussion. > > > > I will add a link to the wiki for the community meetings to collect the > > questions for the forth coming meetings. > > > > Query from me for this meeting to discuss: > > + Having evolution-collab-backends to hold all collab backends ? > > > > - Chenthill. > > > > ___ > > 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
