Re: [os-libsynthesis] How to stop asking for server DevInf
Hi Anuj, On 25.04.2014, at 11:12, Anuj wrote: > While doing sync with server I observed that server is sending a dev inf and > my evolution client is changing the behaviour according to servers dev inf > for further sync sessions. I guess so, because that's the whole point in devInf - allow the sync process to adapt behaviour to the endpoint's capabilities. What benefit would you expect from suppressing that exchange of capabilities? > How do I make my client stop asking for servers dev inf? There's no official way in libsynthesis to achieve that, because all of libsysnthesis is designed to make use of devInf as much as possible. Furthermore, even if you could suppress sending a "Get" command asking for devInf (see syncagent.cpp, lines 1244 ff), this does not necessarily mean the server does not send devInf by itself (using the "Put" command). Best Regards, Lukas signature.asc Description: Message signed with OpenPGP using GPGMail ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] mapping between individual X- extensions and grouped extensions
Hello Patrick, On 25.04.2014, at 21:47, Patrick Ohly wrote: > [...] > > The bigger problem will be on the Evolution side. I don't see how I can > teach libsynthesis that a IMPP entry whose protocol (encoded as part of > the value!) is xmpp maps to X-JABBER. I see no direct way either. > Should I keep the traditional JABBER_HANDLE array and move entries back > and forth between it and the IMPP array? This could be done with > incoming/outgoing resp. afterread/beforewrite scripts. I guess that's the way to go. In particular, I added the incoming/outgoing scripts on the datatypes (looong time ago :-) for very similar problems, after realizing that the formerly pure declarative way to describe vCard/Calendar types was getting more and more complex and still not catching all cases at hand. In the libsynthesis based iOS clients, incoming/outgoing scripts are used a lot for exactly this type of normalizing data for the internal representation. No surprise that the scripting engine got regex support then... The afterread/beforewrite script could do such a conversion as well, however for normalizing data these are executed too late on the server side for normalized data to be used in slow sync matching, so it'll be more complicated to correctly match and merge records. So I'd think doing this in incoming/outgoing scripts would be better. As you said, JABBER_HANDLE would need to be kept as a temporary storage area for the parser to put X-JABBER values into, but the IMPP array would be the actual internal representation for the data. Best Regards, Lukas signature.asc Description: Message signed with OpenPGP using GPGMail ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] [SyncEvolution] mapping between individual X- extensions and grouped extensions
Hi Emiliano, On 26.04.2014, at 12:31, Emiliano Heyns wrote: > Hello! Where do I find more on these scripts? This could be very interesting > for me. The script language is documented in the libsynthesis config reference, see http://cgit.freedesktop.org/SyncEvolution/libsynthesis/tree/doc/SySync_config_reference.pdf To see what scripts are available and when they are run within a sync session, http://cgit.freedesktop.org/SyncEvolution/libsynthesis/tree/doc/SySync_script_call_flow.pdf is helpful. It documents the server side only, but the client flow of calls is not fundamentally different. Note that SyncEvolution already makes use of these scripts for a long time, it's nothing new. Lukas signature.asc Description: Message signed with OpenPGP using GPGMail ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] SyncML Server Performance using Syncevolution
Hi Patrick On Fri, Apr 25, 2014 at 3:29 PM, Patrick Ohly wrote: > > On Fri, 2014-04-25 at 15:03 +0530, Sachin Gupta wrote: > > Hi Lukas/Patrick, > > > > > > I have to run some test cases using syncevolution as client to test a > > SyncML server performance. Expectation is to put load of around 2500 > > users syncing concurrently for an hour. > > That's a bit vague. What kind of changes are supposed to be synced > during that hour? The load will depend a lot on that. At the low end you > just have 2500 users connecting repeatedly without data changing on > client or server. The high end is open-ended; lots of items and slow > syncs will be more expensive than few items and incremental changes. > I would be syncin 1 contact for initial slow sync and post that 100 contacts per user for fast syncs. Not focusing on modifications for now. > > Can you suggest how i can test SyncML Server performance and have 2500 > > users/syncevolutions connecting simultaneously? > > There's no ready-made solution. You'll have to write your own scripts > for configuring SyncEvolution and running the desired benchmark. > > Note that each context in SyncEvolution gets its own device ID. So if > you want to simulate n different devices, use: > > syncevolution --configure ... client-1@client-1 > ... > syncevolution --configure ... client-n@client-n > I figured so. So wrote scripts which will launch syncevo each with unique device ids and seperate user accounts. But the concern is managing these number of syncs through a time period. Exploring if JMETER can help me out in this.\ Also being a process, it would not be possible to launch so many processes in parallel. Memory and CPU would be issues, right? Would need very high end systems for this? Would it be possible doing this launching processes or shall i look into creating threads within the Syncevolution launching and controlling sessions from there? > -- > 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. > > > Regards Sachin ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] SyncML Server Performance using Syncevolution
On Sat, 2014-04-26 at 23:42 +0530, Sachin Gupta wrote: > On Fri, Apr 25, 2014 at 3:29 PM, Patrick Ohly wrote: > > On Fri, 2014-04-25 at 15:03 +0530, Sachin Gupta wrote: > > > Can you suggest how i can test SyncML Server performance and have 2500 > > > users/syncevolutions connecting simultaneously? > > > > There's no ready-made solution. You'll have to write your own scripts > > for configuring SyncEvolution and running the desired benchmark. > > > > Note that each context in SyncEvolution gets its own device ID. So if > > you want to simulate n different devices, use: > > > > syncevolution --configure ... client-1@client-1 > > ... > > syncevolution --configure ... client-n@client-n > > > I figured so. So wrote scripts which will launch syncevo each with > unique device ids and seperate user accounts. > But the concern is managing these number of syncs through a time > period. Exploring if JMETER can help me out in this.\ > Also being a process, it would not be possible to launch so many > processes in parallel. > Memory and CPU would be issues, right? Would need very high end > systems for this? I have not measured this. Try it and you'll see. My expection is that you will need multiple client machines, though. > Would it be possible doing this launching processes or shall i look > into creating threads within the Syncevolution launching and > controlling sessions from there? I would just use multiple client machines. Much simpler and scales perfectly. -- 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. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] mapping between individual X- extensions and grouped extensions
On Sat, 2014-04-26 at 12:30 +0200, Lukas Zeller wrote: > The afterread/beforewrite script could do such a conversion as well, > however for normalizing data these are executed too late on the server > side for normalized data to be used in slow sync matching, so it'll be > more complicated to correctly match and merge records. What do you mean with that? The afterread script gets called after reading and before using the field list, right? So whatever transformation is necessary (for example, X-JABBER -> IMPP) can be done in time before the engine processes the IMPP field. -- 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. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] mapping between individual X- extensions and grouped extensions
On 26.04.2014, at 21:11, Patrick Ohly wrote: > On Sat, 2014-04-26 at 12:30 +0200, Lukas Zeller wrote: >> The afterread/beforewrite script could do such a conversion as well, >> however for normalizing data these are executed too late on the server >> side for normalized data to be used in slow sync matching, so it'll be >> more complicated to correctly match and merge records. > > What do you mean with that? The afterread script gets called after > reading and before using the field list, right? So whatever > transformation is necessary (for example, X-JABBER -> IMPP) can be done > in time before the engine processes the IMPP field. It's the opposite direction I was thinking about: Assuming you chose the IMPP array to internally represent jabber, and further assuming a sync with a peer that uses the X-JABBER format, incoming items would be parsed and compared with existing items (in a slow sync for example) without beforewritescript being run. So you'll compare/merge non-normalized items (those coming from the peer) with normalized ones (those coming from the database). This might not be relevant in the specific SyncEvolution case because of the vCard-based database backend, i.e. the fact that both ends are vCard representations of the data. But for a classical libsynthesis SyncML app with a ODBC or SQLite backend: incoming/outgoing scripts are the place to handle variations in the *representation* of the same data content in vCard, whereas afterread/beforwrite just implements the non-trivial parts of the 1:1 *mapping* of the internal data content to a database backend. Best Regards, Lukas signature.asc Description: Message signed with OpenPGP using GPGMail ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
