Hi Patrick,
On Mar 18, 2010, at 16:22 , Patrick Ohly wrote:
On Thu, 2010-03-18 at 14:05 +, Lukas Zeller wrote:
On Mar 18, 2010, at 14:00 , Patrick Ohly wrote:
Your patch in the luz branch works, thanks a lot.
Thanks for the feedback. After pushing I suddenly had the impression
it
On Tue, 2010-03-16 at 14:40 +, Lukas Zeller wrote:
Most probably, there should be an extra check for that too late
suspend.
Your patch in the luz branch works, thanks a lot.
Now I just have the inverse problem: the tests pass even if the suspend
requests were ignored entirely. Manually
Hello Patrick,
On Mar 18, 2010, at 14:00 , Patrick Ohly wrote:
On Tue, 2010-03-16 at 14:40 +, Lukas Zeller wrote:
Most probably, there should be an extra check for that too late
suspend.
Your patch in the luz branch works, thanks a lot.
Thanks for the feedback. After pushing I
On Thu, 2010-03-18 at 14:05 +, Lukas Zeller wrote:
Hello Patrick,
On Mar 18, 2010, at 14:00 , Patrick Ohly wrote:
On Tue, 2010-03-16 at 14:40 +, Lukas Zeller wrote:
Most probably, there should be an extra check for that too late
suspend.
Your patch in the luz branch works,
Hello Patrick,
On Mar 18, 2010, at 16:22 , Patrick Ohly wrote:
Thanks for the feedback. After pushing I suddenly had the impression
it could still be wrong for another case, I have to follow that
thought first to make sure. So that's why I did not announce the patch
out loud...
It has
On Thu, 2010-03-18 at 15:36 +, Lukas Zeller wrote:
[server admin data]
Yes, it would bypass the API, but unlike with binfiles, in the server
case YOU are the provider of the storage for that admin data, and how
the fields are stored is under YOUR control, and not a secret of the
SyncML
On Mar 18, 2010, at 16:55 , Patrick Ohly wrote:
On Thu, 2010-03-18 at 15:36 +, Lukas Zeller wrote:
[server admin data]
So the format is part of the API? I guess it has to be even though it is
not documented (or is it?), because changes to it would break server
software upgrades.
Hello Patrick,
It seems to me that the client gets confused here. If it cannot suspend,
it should simply complete the session.
I agree with your diagnosis - if it is too late for a client to suspend it
should terminate the session normally, and not do the kind of abort the log
shows here.