moto-sync: Configuration switch for best-effort event conversion

[Steve Wolter]

Hello opensync hackers, hello Andrew,

the moto-sync plugin provides compliance to two motorola event
interfaces, called simple and extended. The simple one is quite
limited and lacks support for some reccurrence rules, including
UNTIL (stop event at certain date) and INTERVAL (only occur every
Nth time).

When encountering a rule it can't convert, moto-sync skips the
event right now, with the intention to avoid displaying any event
that does not happen. Unfortunately, that excludes quite some
events from being uploaded.

However, by using the (limited to a small number, I admit) Motorola
phone's ability to honor exceptions to events, one could partially
implement these features fairly easily. For example, an event which
happens every 2 weeks might be modeled by using one which happens
every week, but not on occurrences 1, 3, 5, 7, [...], counting from
0.
This would display more events, but display too many occurrences
for the distant future (for weekly events with interval 2 on my
V3x, 16 weeks).

It is my humble opinion that, if given the choice between dis-
playing too many events and too few, I'd like to see too many
and not forget about some event that isn't displayed at all.
But since this is just my humble opinion, it should not be hard-
coded: Rather I'd like to introduce a configuration switch for
moto-sync that will switch between the standard conservative
behaviour and the more daring scheduling displayed above.

What do you think of this?

Regards, Steve

--
Steve Wolter (Univ. of Bielefeld)| Web page: http://swolter.sdf1.org
                                 | vCard:    http://swolter.sdf1.org/swolter.vcf
 A witty saying proves nothing.  | Schedule: http://swolter.sdf1.org/swolter.ifb
    -- Voltaire (1694-1778)      | E-mail:   swolter@...


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Thursday 17 April 2008 10:11:06 Steve Wolter wrote:

> the moto-sync plugin provides compliance to two motorola event
> interfaces, called simple and extended. The simple one is quite
> limited and lacks support for some reccurrence rules, including
> UNTIL (stop event at certain date) and INTERVAL (only occur every
> Nth time).
>
> When encountering a rule it can't convert, moto-sync skips the
> event right now, with the intention to avoid displaying any event
> that does not happen. Unfortunately, that excludes quite some
> events from being uploaded.

Can't this be handled by capabilities and merger?


> However, by using the (limited to a small number, I admit) Motorola
> phone's ability to honor exceptions to events, one could partially
> implement these features fairly easily. For example, an event which
> happens every 2 weeks might be modeled by using one which happens
> every week, but not on occurrences 1, 3, 5, 7, [...], counting from
> 0.
> This would display more events, but display too many occurrences
> for the distant future (for weekly events with interval 2 on my
> V3x, 16 weeks).

AFAIK, we hit similar problems with older phones - especially IrMC based one
(IIRC).

> It is my humble opinion that, if given the choice between dis-
> playing too many events and too few, I'd like to see too many
> and not forget about some event that isn't displayed at all.
> But since this is just my humble opinion, it should not be hard-
> coded: Rather I'd like to introduce a configuration switch for
> moto-sync that will switch between the standard conservative
> behaviour and the more daring scheduling displayed above.

I wonder if most of this could be done with the use of Capabilities/Merger and
extensive use of Filters.

best regards,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Friday 18 April 2008 11:45:56 Daniel Gollub wrote:
> I wonder if most of this could be done with the use of Capabilities/Merger
> and extensive use of Filters.

Saying that is quite easy ;) The filter is not completed yet and not used
anywhere. There is just some initial code. But maybe it's worth to take a
look - maybe the unittests of the filter code  is a good starting point.

Steve, i would try to have a more generic solution since there are quite some
enhancment requests which are about handling different capabilities and
workaround missing features on mobiles. (I guess this is what it's all about
right?)

But since generic solution are next to impossible to implement and wasting
lots of time - i would be also fine with a plugin specific workaround for
time being. But any suggestion would we would need to change in OpenSync
itself to make it working is very appricated.

best regards,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Steve Wolter-5]

Hello Opensync developers,

Daniel Gollub wrote:
> But since generic solution are next to impossible to implement and wasting
> lots of time - i would be also fine with a plugin specific workaround for
> time being. But any suggestion would we would need to change in OpenSync
> itself to make it working is very appricated.

Well, the code I've got in an early version here is quite generic and
not moto-specific at all. Actually, it could even be an XSL-ified trans-
formation on the XML event format.

What one would basically need for a generic implementation is:
a) A way to express "Can do RecurrenceRule, but not RecurrenceRule/Interval"
   If I got the whole capabilities thing right, it would suffice to
   extend the algorithm to check children of supported nodes as well.
b) A way to express "If can not do RecurrenceRule/Interval, but can do
   RecurrenceRule/Exception, transform in way X".

Now, here is the interesting part:

What do these mergers you spoke of _do_? The code says something like
"Merge all xmlfields from the entire xmlformat into the xmlformat if
they are not listed in the capabilities."
What merging? Does a merger actually do any conversion or will it
take the supported fields from an object and detect conflicts in
the merged object?
Is the merger in the up-stream from plugins to core or in the
down-stream of finished objects in core to plugins?

I'd volunteer to take the filter scheme and convert it to a make-like
model (target, prerequisite, tree-search), but I'd need to know the
great picture of the current model first.
Once the engine has merged all changes into a common "model", which
path does the object take before the plugin gets it?
Is there any documentation you could point me to?

Regards, Steve

--
Steve Wolter (Univ. of Bielefeld)| Web page: http://swolter.sdf1.org
                                 | vCard:    http://swolter.sdf1.org/swolter.vcf
 A witty saying proves nothing.  | Schedule: http://swolter.sdf1.org/swolter.ifb
    -- Voltaire (1694-1778)      | E-mail:   swolter@...

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub]

On Sunday 20 April 2008 18:46:26 Steve Wolter wrote:
> Daniel Gollub wrote:
> > But since generic solution are next to impossible to implement and
> > wasting lots of time - i would be also fine with a plugin specific
> > workaround for time being. But any suggestion would we would need to
> > change in OpenSync itself to make it working is very appricated.
>
> Well, the code I've got in an early version here is quite generic and
> not moto-specific at all. Actually, it could even be an XSL-ified trans-
> formation on the XML event format.

Interesting, could you send the code as patch to the list?

>
> What one would basically need for a generic implementation is:
> a) A way to express "Can do RecurrenceRule, but not
> RecurrenceRule/Interval" If I got the whole capabilities thing right, it
> would suffice to extend the algorithm to check children of supported nodes
> as well.

For this the capabilities are intended, to express which members support
which "fields". In case of RecurrenceRule we have simialar problems with
compatibly between vCalendar and iCalendar. The "grama" of iCalendar is
different and is able to represent constalation of recurrence which vCalendar
is not able to do.


> b) A way to express "If can not do RecurrenceRule/Interval, but
> can do RecurrenceRule/Exception, transform in way X".

We decided to have in our xmlformat two different RecurrenceRule fields:

RecurrenceRule and RecurrenceRuleExtended.
The Exception stuff is a different field - but is the same as RecurrenceRule
and RecurrenceRuleExtended.

Check:

./misc/schemas/xmlformat-event.xsd
./misc/schemas/xmlformat-calendar.xsd

Not quite sure whats the need of "transform in way X" - sounds like a "hook"
function.

>
> Now, here is the interesting part:
>
> What do these mergers you spoke of _do_? The code says something like
> "Merge all xmlfields from the entire xmlformat into the xmlformat if
> they are not listed in the capabilities."

> What merging? Does a merger actually do any conversion or will it
> take the supported fields from an object and detect conflicts in
> the merged object?
> Is the merger in the up-stream from plugins to core or in the
> down-stream of finished objects in core to plugins?


FOSDEM 2007 there was a presentation about OpenSync, which also introduced the
Merger: http://cryptomilch.de/~dgollub/talks/OpenSync_FOSDEM_2007.pdf

http://opensync.org/wiki/Merger


> I'd volunteer to take the filter scheme and convert it to a make-like
> model (target, prerequisite, tree-search), but I'd need to know the
> great picture of the current model first.
> Once the engine has merged all changes into a common "model", which
> path does the object take before the plugin gets it?

Once all conflicts got solved the change object get multiplied for all
members. For each member the demerger removes fields, which are unsupported
by the member. At this point the change is still in the XMLFormat-*. When the
demerger is ready the change in XMLFormat gets converted in a format
supported by the plugin. Then this converted change gets send to the plugin
via the IPC. Depending on the plugin, this turns out to serveral call of the
commit() function or single call of batch_commit().

So far the filter is not involved. Not quite sure yet where the best place is
to get the filter involved. But very likely even before the multiply for each
member - since some filter rules could reject a change entry for a particular  
member.

> Is there any documentation you could point me to?
I guess the whitepaper is still lacking in this area... i try to fill the gap
in this area in the next days. But in meanwhile don't hesitate to ask whats
lacking in documentation.

I hope this helped somehow.

best regards,
Daniel

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Andrew Baumann-2]

Hi Steve,

On Thursday 17 April 2008, Steve Wolter wrote:

> When encountering a rule it can't convert, moto-sync skips the
> event right now, with the intention to avoid displaying any event
> that does not happen. Unfortunately, that excludes quite some
> events from being uploaded.
>
> However, by using the (limited to a small number, I admit) Motorola
> phone's ability to honor exceptions to events, one could partially
> implement these features fairly easily. For example, an event which
> happens every 2 weeks might be modeled by using one which happens
> every week, but not on occurrences 1, 3, 5, 7, [...], counting from
> 0.
> This would display more events, but display too many occurrences
> for the distant future (for weekly events with interval 2 on my
> V3x, 16 weeks).

To give some background as to why I did this, the motivation was:
1. I was lazy :)
2. If you decide to implement a single high-level recurring event as a whole
lot of smaller events on the phone, the phone has no notion that these are
the same event. This makes operations like deleting an event, or changing it
and subsequently reflecting those changes in the other sync members on a sync
very very messy. Worse, even if you deal with the trickery of identifying
that all the sub-events are part of some larger event, if you ever have to do
a slow-sync this information isn't available, and suddenly your other group
members (like your PIM app) see all the small events you created
to "fake-out" the single complex recurring event.

So it seemed to bring up a big can of worms that I preferred just to avoid. A
simpler solution may just be to avoid sending any recurring events to the
phone, splitting them up into lots of single events in opensync or in the
plugin.

> It is my humble opinion that, if given the choice between dis-
> playing too many events and too few, I'd like to see too many
> and not forget about some event that isn't displayed at all.
> But since this is just my humble opinion, it should not be hard-
> coded: Rather I'd like to introduce a configuration switch for
> moto-sync that will switch between the standard conservative
> behaviour and the more daring scheduling displayed above.
>
> What do you think of this?

I think it would be great; good luck :) But I'd like a config option to avoid
it as you propose.

If there is a way to implement this in the OpenSync core, as Daniel proposes,
that would of course be better.

Cheers,
Andrew

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel