View Single Post
Old 2009-01-19, 09:45
luz's Avatar
luz luz is offline
Join Date: 2006-06
Posts: 348
Default Re: iPhone TODO+SYNC bugs/wishes

I have about 2300 events in my calendar. All the calendar views need several seconds to become functional after starting the application. Would be nice if this "boot-time" could be a little bit shorter and the "event-overview" would not studder so much when I'm scrolling.
We are working to optimize the calendar database such that its performance gets less dependent on the total number of events.
But still, generally it is a good idea to restrict the number of events synchronized to mobiles to what is really needed to be there, usually by defining a time window (like 90 days before and 90 days after today). However, Todo+Cal+Sync cannot do that itself, as it needs server support. Unfortunately not all servers support this yet. I'm not sure about Horde.

But the main problem I have is, that the events-sync synchronizes only up to "today" when doing a slow sync. New/Updated events added on the Server after the initial slow-sync are synced allright, but no event having been there before ever appeares on the iPhone. Since the Palm-Version of the syncML-Client works just fine, I assume there is something wrong with the iPod-Version.
This definitely must be a server-side strategy or bug, because in SyncML the client has no control over what the server does or doesn't send. The only thing the client can do is requesting filtering (like with the "only x days before and y days after today option), but as said above not all servers support that.

Note that while originating from the same SyncML engine, Todo+Cal+Sync still different from the PalmOS version, so it might well be the iPhone version is treated differently by the server).

Bottom line: That's something the horde folks should look at (in the logs) first - of course if they have any question or think our client is misbehaving, they can contact us directly (we have sorted out issues in cooperation with them already in the past).
Lukas Zeller,
Reply With Quote