Re: [os-libsynthesis] vCard group tags
On Tue, 2014-04-29 at 18:00 +0200, Lukas Zeller wrote: Hi Patrick, you are faster in understanding the details than I could look them up :-) Live and learn. Or use the source, Luke ;-) However, it helps to spell out observations and thoughts occasionally, so let me continue with a related problem. I decided that a separate X-ABLabel for every TEL, ADR, X-ABDate, X-ABRELATEDNAMES, etc. is too verbose and too different from traditional usage of vCard. Recipients of such a vCard must be able to understand and support groups, which is not guaranteed. For example, the Evolution vCard parser supports groups, but the higher level of abstraction does not (or not easily). I also don't see what advantage X-ABLabel as property has over X-ABLabel as parameter. I understand that a property could itself have parameters or complex values, but that's not the case here. A simple string might just as well be attached as parameter. So that's what I am trying to do: 1. Parse with groups: X-ABLabel property enabled. 2. Throw away group tags. 3. Generate with parameter: X-ABLabel parameter enabled. This direction works. What fails is reading such a generated vCard, because different properties store their X-ABLabel parameter in the same LABEL field array, overwriting each others' values. The logic for choosing a position must now also (or instead?!) check whether the LABEL position is unused when adding a new ADR. In other words, when parsing an ADR, look at LABEL to determine the position. I thought I could achieve that with: property name=X-ABLabel suppressempty=yes groupfield=GROUP_TAG rule=HAVE-ABLABEL-PROPERTY value field=LABEL repeat=array increment=1 minshow=0/ position field=LABEL repeat=array increment=1 minshow=1/ /property property name=ADR values=7 groupfield=GROUP_TAG value index=0 field=ADR_POBOX/ value index=1 field=ADR_ADDTL/ value index=2 field=ADR_STREET/ value index=3 field=ADR_CITY/ value index=4 field=ADR_REG/ value index=5 field=ADR_ZIP/ value index=6 field=ADR_COUNTRY/ position field=LABEL repeat=array increment=1 minshow=1/ parameter name=TYPE default=yes positional=no show=yes value field=ADR_STREET_FLAGS conversion=multimix combine=, enum name=HOME value=B0/ enum name=WORK value=B1/ enum mode=ignore value=B2/ !-- OTHER -- !-- enum mode=prefix name=X-CustomLabel- value=1.L/ -- !-- enum mode=prefix name=X-Synthesis-Ref value=2.L/ -- /value /parameter parameter name=X-ABLabel rule=HAVE-ABLABEL-PARAMETER value field=LABEL/ /parameter /property However, when parsing a vCard with HAVE-ABLABEL-PARAMETER unset and HAVE-ABLABEL-PROPERTY set, sysync::TMimeDirProfileHandler::parseProperty() goes into an endless loop involving sysync::TMultiFieldItem::adjustFidAndIndex() directly on the first ADR: ADR;TYPE=HOME:PO;neighborhood;home address\n;City;State;ZIP;Country It's permanently increasing repoffset. I've not looked further, but I suspect that this is because of using LABEL twice, once indirectly via the group field and once via the position field. I'll try applying different property elements, even if that means more duplication in the profile. -- 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] vCard group tags
On Wed, 2014-04-30 at 18:22 +0200, Lukas Zeller wrote: What you have here is probably the most elaborate profile ever specified for libsynthesis :-) , but I see no reason why it should not work once the position is correct. That's what I had tried earlier. It leads to the situation where the labels of independent properties overwrite labels of other, earlier properties. That's because the position checking seems to focus exclusively on property values and ignores property parameters. Here's an example: BEGIN:VCARD VERSION:3.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.47//EN REV:20140430T170257Z N:Doe;John;1;Mr.;Sr. FN:Mr. John 1 Doe Sr. X-EVOLUTION-FILE-AS:Doe\, John X-GENDER: NICKNAME:Johnny TITLE:tester ORG:at company;;; ROLE: TEL;TYPE=WORK:business 1 TEL;TYPE=CELL:mobile TEL;TYPE=HOME:home TEL:main TEL;TYPE=WORK,FAX:work fax TEL;TYPE=HOME,FAX:home fax TEL;X-ABLabel=Google Voice:google voice TEL;TYPE=PAGER:pager TEL;X-ABLabel=custom-label4:custom EMAIL;TYPE=HOME:john@home.com EMAIL;TYPE=WORK:d...@work.com EMAIL;X-ABLabel=custom-label2:j...@custom.com URL;X-ABLabel=Profile:http://profile.com URL;X-ABLabel=Blog:http://blog.com URL;X-ABLabel=HomePage:http://homepage.com URL;X-ABLabel=Work:http://company.com URL;X-ABLabel=Custom-label6:http://custom.com X-EVOLUTION-MANAGER:manager X-MANAGER:manager X-EVOLUTION-ASSISTANT:assistant X-ASSISTANT:assistant X-ABRELATEDNAMES;X-ABLabel=Child:child X-ABRELATEDNAMES;X-ABLabel=Mother:mother X-ABRELATEDNAMES;X-ABLabel=Father:father X-ABRELATEDNAMES;X-ABLabel=Parent:parent X-ABRELATEDNAMES;X-ABLabel=Brother:brother X-ABRELATEDNAMES;X-ABLabel=Sister:sister X-ABRELATEDNAMES;X-ABLabel=Friend:friend X-ABRELATEDNAMES;X-ABLabel=relative:relative X-ABRELATEDNAMES;X-ABLabel=referred by:referred-by X-ABRELATEDNAMES;X-ABLabel=Partner:partner X-ABRELATEDNAMES;X-ABLabel=domestic partner:domestic partner X-ABRELATEDNAMES;X-ABLabel=custom-label5:custom relationship X-EVOLUTION-SPOUSE:spouse X-SPOUSE:spouse X-EVOLUTION-ANNIVERSARY:19710101 X-ANNIVERSARY:19710101 X-ABDate;X-ABLabel=custom-label3:2201 IMPP;X-ABLabel=Other:xmpp:google%20talk IMPP;X-ABLabel=Other:aim:aim IMPP;X-ABLabel=Other:ymsgr:yahoo IMPP;X-ABLabel=Other:skype:skype IMPP;X-ABLabel=Other:x-apple:QQ IMPP;X-ABLabel=Other:msnim:MSN IMPP;X-ABLabel=Other:aim:ICQ IMPP;X-ABLabel=Other:xmpp:Jabber IMPP;X-ABLabel=Other:x-apple:custom%20chat X-MOZILLA-HTML:FALSE ADR;TYPE=HOME:PO;neighborhood;home address\n;City;State;ZIP;Country ADR;TYPE=WORK:;;work address ADR:;;custom address BDAY:19701230 NOTE:A test contact. PHOTO;ENCODING=B:iVBORw0KGgoNSUhEUgAAACQXCAYAAABj7u2bBmJLR0QA/wD/AP+gvaeTCXBIWXMAAAsTAAALEwEAmpwYB3RJTUUH1gEICjgdiWkBOQAAAB10RVh0Q29tbWVudABDcmVhdGVkIHdpdGggVGhlIEdJTVDvZCVuAAABaElEQVRIx+3Wu0tcURAG8F98gRKTYGORRqwksJV/QOqFFIFgKgsRYbHV1larDQQCKQxpUscyhUmXJuCSNpYWPsAU6wPxHW6aWbgsu+ve3RUs7geHc+fON3O+M4c5HHLkyHG/eISkg5heIGmUr++hVWigyY6THlejbWSt0Bv8QBXX2MF7jKU4IyjjJ45xg31sYKZuw7Xv9Gh6vvXO9QbBtbGNJ8Ert+AlTURkFjQX9g5e4ykGUcBm+FaDexx2MUQOYhIL2Lpj09oV9CvsQgPuePj+hP037BL6M6yRSdDZHWVOcBHcEv7FvyN8xxqmeynovA1Baf4UVvANhyn/Uq8E/Q57ssNufhvx1QZrDHfS9p9i3sQsnscdNowXWEQlOBXMYyI4j3EavqFUzpOYl4OTqUJ9+NzmkbXyb6Ryfumm7Wso4it2cYXL6K6PeBmcV8E5iEvxPDjv8CyVaxQfsIfbqGIlf17k6Bb/Ae0cnahfg6KuAElFTkSuQmCC GEO:; X-PHONETIC-FIRST-NAME:John X-PHONETIC-LAST-NAME:Doe END:VCARD * [2014-04-30 19:03:12.551] parseMimeDir: property X-EVOLUTION-MANAGER parsing delayed, rank=1 * [2014-04-30 19:03:12.551] parseMimeDir: property X-EVOLUTION-ASSISTANT parsing delayed, rank=1 * [2014-04-30 19:03:12.551] parseMimeDir: property X-EVOLUTION-SPOUSE parsing delayed, rank=1 * [2014-04-30 19:03:12.551] parseMimeDir: property X-EVOLUTION-ANNIVERSARY parsing delayed, rank=1 * [2014-04-30 19:03:12.551] parseMimeDir: now parsing delayed property rank=1: :manager X-MANAGER:manager X * [2014-04-30 19:03:12.552] parseMimeDir: now parsing delayed property rank=1: :assistant X-ASSISTANT:assist * [2014-04-30 19:03:12.552] parseMimeDir: now parsing delayed property rank=1: :spouse X-SPOUSE:spouse X-EV * [2014-04-30 19:03:12.552] parseMimeDir: now parsing delayed property rank=1: :19710101 X-ANNIVERSARY:19710 * [2014-04-30 19:03:12.552] Successfully parsed: * [2014-04-30 19:03:12.552] Item LocalID='', RemoteID='1a1d5ecf8e36d276', operation=add, size: [maxlocal,maxremote,actual] * [2014-04-30 19:03:12.552] - 0 :integer SYNCLVL [ n/a, 0, 0] : unassigned - 1 : timestamp REV [ 0, 0, 0] : 2014-04-30T17:02:57Z (TZ: UTC) - 2 : string UID [ n/a, 0, 0] : unassigned - 3 : string GROUP_TAG [ n/a, 0, 0] : array with 12 elements -- element0 : empty -- element1 : empty -- element2 : empty -- element3 : empty
Re: [os-libsynthesis] SyncML Server Performance using Syncevolution
but that will require a lot of client machines that too of higher configurations. What we are seeing rt now is high cpu usage (even though for a very short time period). Trying to debug the cause for the same. if i assume that 100 processes can be invoked from one system, then also i need ~24 systems :( Regards On Tue, Apr 29, 2014 at 11:53 PM, Patrick Ohly patrick.o...@intel.com wrote: On Tue, 2014-04-29 at 23:22 +0530, Sachin Gupta wrote: one more thing. everytime i invoke syncevolution, it has to load all the xmls, build up its data structures, and all the other stuff. Can i implement threads in it and run it as a daemon. This will i can save time from doing all this. From within, can i then implement threads and launch multiple sync operations? Multithreading is not going to work. You should be able to run a sync repeatedly in the same process, but reusing the XML loading will require putting the loop fairly deeply into the SyncEvolution stack (see SyncContext.cpp). I'm still not sure why you want to do this when you can simply use more client machines. It might safe you some time for setting up a cluster if (and only if!) you can manage to run all clients from the same machine, but I have my doubts whether that will be possible. -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Open Source Technology Center Usenerstr. 5a Phone: +49-228-2493652 53129 Bonn Germany ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
