Thanks Patrick. "It depends on whether the server uses the sent DevInf at all". This statement helped a lot :)
You were right!. Funambol is not considering the device capabilities. I tested by removing the TEL property from client devinf, but still Funambol did not take this into consideration and as part of the refresh-from-server, Funambol sent the complete TEL information. I will now try deploying syncevo as a server and try synncing with this. T&R Sachin On Wed, Nov 27, 2013 at 1:08 PM, Patrick Ohly <[email protected]> wrote: > On Wed, 2013-11-27 at 12:44 +0530, Sachin Gupta wrote: >> Somehow i was able to modify the devinf information being sent from >> client to remote Server. >> Had to hack the libsynthesis code for this. Though the engine still >> dumps the original devinf in outgoing.xml, server gets the modified >> devinf. >> >> I modified the syncagent.cpp of libsynthesis code in function >> TSyncAgent::NextMessage just before it enters FinishMessage and >> replace the already formed DevInf information. > > Yes, low-level hacking of course always is an option. It's just software > after all ;-} > >> Sync happened with the modified devinf, but am not sure what are the >> repurcussions of modifiying the devinf in memory on client side. How >> will the client behave to syncs sent from server? > > It depends on whether the server uses the sent DevInf at all. > > The Synthesis server definitely does. If the client claims to not > support, say, ADR, then the client cannot remove that piece of > information on the server because the server will always keep the data > intact during updates. > > If I remember correctly, the Funambol server only checked the PHOTO > entry. It only sent photos if that was present, at least with some > phones. Better ask Funambol. > > I don't know about other servers. > > -- > 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. > > _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
