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
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 reasons, among them change tracking and concurrent editing
of items.
13 matches
Mail list logo