Re: [os-libsynthesis] optional property parameters, sub/remoterules

[Lukas Zeller]

On Sep 8, 2010, at 16:25 , Lukas Zeller wrote:

> I'm now in the process of merging some updates on our side and will push them 
> onto luz in the next hour or so (but leave master at its current position for 
> now).

Done, and tagged as libsynthesis_3.4.0.16 in our git in the luz branch.

Two notes regarding these changes (the rest should be fully transparent for the 
apps using libsynthesis):


1) 0e139ee311 (engine 3.4.0.10: separate changelogs, pendingmaps and 
pendingitem for each profile to allow for different syncsets in profiles (as 
needed by SyncML PRO iOS)):

This change is transparent as long as the app using libsynthesis does not mess 
with the *.bfi files directly, especially make assumptions about their names. 
It is possible to stay with the old unified changelog for applications not 
using more than one profile (by explicitly turning off the new separate 
changelogs in the config), but I would recommend to use the new way because the 
old way is deprecated and might be removed entirely later.


2) 4275e77001 (engine: refined folding for pre-MIME-DIR and MIME-DIR - new 
"foldbetween"  attribute.):

This changes the way folding occurs in pre-MIME-DIR formats (vCard 2.1, 
vCalendar 1.0), as it no longer inserts extra spaces to break long multi-value 
properties with no spaces in the values, but instead uses QP (as it already did 
for single-value properties with no spaces in the value). However, as the new 
(correct) behaviour probably causes more troubles for poor implementation with 
multi-values like EXDATE, there's now a new property-level config option to 
allow inserting a space between value and value separator when needed to wrap 
long lines. With this, EXDATE is rendered similar as before (before the spaces 
were inserted AFTER the separator, which caused a extra LEADING space, while 
now it will be an extra TRAILING space).

So the recommendation is to add foldbetween="yes" in the config for EXDATE (and 
possibly other semantically similar properties).

All this only affects *generation* of vXXX and only the pre-MIME-DIR mode.

Except that the fully transparent folding mechanism in MIME-DIR will now also 
prefer folding multi-values after a value separator if possible (but this is 
merely cosmetic, as it makes generated iCalendar with EXDATEs more 
human-readable).


___
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Re: [os-libsynthesis] optional property parameters, sub/remoterules

[Lukas Zeller]

Hello Patrick,

thanks a lot for implementing this!

I just reviewed the changes and found no objections. So I updated our git 
master and luz branches with it.

I'm now in the process of merging some updates on our side and will push them 
onto luz in the next hour or so (but leave master at its current position for 
now).

Best Regards,

Lukas


On Sep 3, 2010, at 18:08 , Patrick Ohly wrote:

> On Thu, 2010-09-02 at 11:48 +0200, Patrick Ohly wrote:
>> Now I would go one step further and suppress generating this parameter
>> for a peer, after identifying the peer. I thought that this should be
>> possible with the remoterule config option, but  doesn't
>> support that according to the documentation. BTW, the config parser
>> doesn't complain when it is specified, it just doesn't do anything.
>> 
>> Is adding support for it a good idea? The semantic would be "during
>> parsing and generating, ignore parameter unless no remoterule set or
>> rule is active". I'm a bit uncertain whether this should apply during
>> parsing *and* generating, because parsing something that was sent to us
>> shouldn't do any harm. But it wouldn't be consistent.
> 
> I've implemented this and verified that it does what we need by adapting
> SyncEvolution.
> 
> Attached are the patches, also pushed to meego.gitorious.org in the
> parameter-rule branch. Does that look acceptable? I'd prefer to use them
> in SyncEvolution 1.1 only after a review by Synthesis.
> 
>> MAKETEXTWITHPROFILE(... "EVOLUTION")
>> 
>> Except that the last step doesn't work yet either. Would it make sense
>> to extend TMimeDirProfileHandler::setRemoteRule() such that setting a
>> rule also sets all included rules?
> 
> This is what I implemented. It has the advantage that the choice about
> full recursion can be made differently in different situations.
> 
> -- 
> 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.
> 
> <0001-MIME-Profile-added-parameter-rule-something.patch><0002-MIME-Profile-check-parameter-rule-something-when-gen.patch><0003-MIME-Profile-check-parameter-rule-something-when-par.patch><0004-MIME-Profile-setting-one-rule-also-activates-all-inc.patch>___
> os-libsynthesis mailing list
> os-libsynthesis@synthesis.ch
> http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Lukas Zeller (l...@synthesis.ch)
- 
Synthesis AG, SyncML Solutions  & Sustainable Software Concepts
i...@synthesis.ch, http://www.synthesis.ch





___
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis