Hello Patrick, I don't think buffering for retries belongs into the engine. We always had it at the transport level, exactly for reasons being able to resend last message without need to keep entire session alive etc.
Now what was missing was that canBufferRetryAnswer() always returns no in libsynthesis. So I added a config option called <buffersretryanswer>, which is off by default, but can be set in a config for an app that implements answer buffering on the transport level. When that option is set, the (server app) caller of SessionStep must be aware of the following condition: - SessionStep() can return STEPCMD_RESENDDATA, which means in the server case that the previous response needs to be resent, rather than getting a new one from the engine. - The sessionstep state machine is expecting a STEPCMD_SENTDATA as the next step, which will return STEPCMD_NEEDDATA again and wait for the next client request. I just pushed a patch for that in 0f7a2b0f03 (server engine: added option to implement client resent message handling.) Best Regards, Lukas Zeller On Feb 26, 2010, at 10:41 , Patrick Ohly wrote: > On Fri, 2010-02-26 at 06:51 +0000, Patrick Ohly wrote: >> The only implementation of canBufferRetryAnswer() that I find returns >> "false", so we end up in the else branch and indeed, in some cases the >> state gets messed up. >> >> I'll keep looking into how I can enable this. Hints welcome. > > I've got it working, but only in a hackish way. See > libsynthesis-resend.patch. It depends on the app knowing about > STEPCMD_RESENDDATA *and* buffering the last reply itself. I consider > this a hack a) because canBufferRetryAnswer() can't know whether the app > is capable of resending and b) the buffering should be inside the > engine, using the normal STEPCMD_SENDDATA. > > I also tried STEPCMD_SENDDATA, but found that the content of the SML > message buffer was too messed up to get the old reply. > > I'm also attaching the SyncEvolution patch necessary to support the hack > above. This is only for future reference, because I am not going to > commit it to our repo. > > With these patches I get our tests to pass mostly, but the known issue > with not being able to resend the last reply in a session still breaks > it. This can only be fixed inside libsynthesis and/or SyncEvolution by > keeping sessions alive after the server considers them "done", which > complicates the session handling considerably. > > I found it easier to add caching of the last reply to our > syncevo-http-server.py script. It does not depend on the SyncML message > number (server cannot parse the message), instead it does a byte > comparison of the incoming message. Obviously that depends on the client > sending exactly the same data, but for SyncEvolution as client that > works. Lukas, do you know whether other clients (like the Nokia phones) > do the same? > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > <libsynthesis-resend.patch><syncevolution-resend.patch> Lukas Zeller ([email protected]) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts [email protected], http://www.synthesis.ch _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
