[SyncEvolution] Re: new SyncEvolution binaries, dropping features?

[Patrick Ohly]

deloptes <deloptes at gmail.com> writes:
> On Mon, Aug 3, 2020 at 4:16 PM Patrick Ohly <patrick.ohly at intel.com> wrote:
>
>> Emanoil Kotsev <deloptes at yahoo.com> writes:
>> >  Hi,
>> > It is the file UPGRADING.txt in openobex not the README
>> > Upgrading to version 1.7Upgrading to version 1.6
>>
>> 1.7 is ancient (released 2016). I remember reading about "When using an
>> event loop that triggers on incoming data, you must call
>> OBEX_HandleInput() after each call to OBEX_Request() to actually send
>> the request"
>> (https://gitlab.com/openobex/mainline/-/blob/master/UPGRADING.txt).
>> If I remember correctly, my conclusion was that SyncEvolution does that,
>> but I am not sure anymore.
>>
>>
> I am also not sure where and how this has to be done. I think I have looked
> into SyncEvolution few years ago and it seemed to call OBEX_HandleInput(),
> but I am not quite sure at all. It could be also something completely
> different.

Perhaps calling OBEX_HandleInput unconditionally after OBEX_Request is
really missing. I don't know exactly whether it now gets called only
when the fd is ready.

> In theory it should be possible that one end is using openobex-1.5 and the
> other 1.7 - the protocol is the same, so I do change only openobex on one
> end at a time. I don't know if I change on both ends it would start
> working. Do you think it is worth trying?

No, changing only one side is the right approach. I also doubt that
updating both sides will magically solve it - that would imply that
openobex is no longer compatible with other OBEX implementations.

-- 
Best Regards

Patrick Ohly
_______________________________________________
SyncEvolution mailing list -- syncevolution at syncevolution.org
To unsubscribe send an email to syncevolution-leave at syncevolution.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s