On Tue, 2009-07-28 at 13:05 +0530, Chenthill wrote:
> On Fri, 2009-07-24 at 20:20 +0200, Patrick Ohly wrote:
> > I have not looked at the calendar API yet. Let me know what you think
> > about the attached patch for a new ebook API and I will continue with
> > calendar next, before implementing any
On Fri, 2009-07-24 at 20:20 +0200, Patrick Ohly wrote:
> Hello!
>
> Let's pick up this discussion again. When we agree on the API changes,
> then I'll try to follow up with an implementation for the file backend.
>
> On Thu, 2009-01-08 at 13:48 +0100, Patrick Ohly wrote:
> > Hello Suman!
> >
> >
Hello!
Let's pick up this discussion again. When we agree on the API changes,
then I'll try to follow up with an implementation for the file backend.
On Thu, 2009-01-08 at 13:48 +0100, Patrick Ohly wrote:
> Hello Suman!
>
> I forgot to ask: do you agree in general with the plan to do atomic
> up
On Thu, Jan 8, 2009 at 15:19, Patrick Ohly wrote:
>> The GroupWise server updates the 'modified' property of the item when
>> it actually gets modified on the server. For newly created items, it
>> also adds the 'created' property at the same time.
>>
>> This behavior invalidates all the 'handle-a
On Wed, 2009-01-07 at 12:45 +0100, Patrick Ohly wrote:
> Hello!
>
> I'm currently thinking about synchronizing data with SyncEvolution in
> the background while the user is active with the Evolution UI. Some
> users already do that via cron jobs, but it is known to be problematic
> for several rea
On Thu, 2009-01-08 at 10:49 +0100, Patrick Ohly wrote:
> On Thu, 2009-01-08 at 10:10 +0530, Suman Manjunath wrote:
> > On Wed, Jan 7, 2009 at 17:15, Patrick Ohly wrote:
> > > The plan for change tracking is to get rid of the dependency on
> > > e_book_get_changes(). I already stopped using e_cal_g
Hello Suman!
I forgot to ask: do you agree in general with the plan to do atomic
updates via e_book_commit_contact() and e_cal_modify_object() by
defining the semantic as suggested?
I also need to extend the proposal: removing an item has similar race
conditions (sync starts, user updates item, s
On Thu, 2009-01-08 at 10:10 +0530, Suman Manjunath wrote:
> On Wed, Jan 7, 2009 at 17:15, Patrick Ohly wrote:
> > The plan for change tracking is to get rid of the dependency on
> > e_book_get_changes(). I already stopped using e_cal_get_changes()
> > because it was too inflexible. Instead I'll re
On Wed, Jan 7, 2009 at 17:15, Patrick Ohly wrote:
> The plan for change tracking is to get rid of the dependency on
> e_book_get_changes(). I already stopped using e_cal_get_changes()
> because it was too inflexible. Instead I'll rely on the REV resp.
> LAST-MODIFIED properties: the backend must u
Il giorno mer, 07/01/2009 alle 12.45 +0100, Patrick Ohly ha scritto:
> Hello!
>
> I'm currently thinking about synchronizing data with SyncEvolution in
> the background while the user is active with the Evolution UI. Some
> users already do that via cron jobs, but it is known to be problematic
> f
On Wed, 2009-01-07 at 16:05 +0100, Milan Crha wrote:
> On Wed, 2009-01-07 at 12:45 +0100, Patrick Ohly wrote:
> > ...
> > The plan for change tracking is to get rid of the dependency on
> > e_book_get_changes(). I already stopped using e_cal_get_changes()
> > because it was too inflexible. Instead
On Wed, 2009-01-07 at 12:45 +0100, Patrick Ohly wrote:
> ...
> The plan for change tracking is to get rid of the dependency on
> e_book_get_changes(). I already stopped using e_cal_get_changes()
> because it was too inflexible. Instead I'll rely on the REV resp.
> LAST-MODIFIED properties: the back
12 matches
Mail list logo
