|
»
»
« Return to Thread: moto-sync: Configuration switch for best-effort event conversion
Re: moto-sync: Configuration switch for best-effort event conversion
by Andrew Baumann-2
::
Rate this Message:
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
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
« Return to Thread: moto-sync: Configuration switch for best-effort event conversion
| Free Forum Powered by Nabble | Forum Help |