On Feb 28, 2008, at 9:13 AM, Randy Letness wrote:
Mimi Yin wrote:
1. Are we corrupting data? Losing data, changing data, etc.
There are two types of interop bugs. The first type is where the
server is doing something wrong, or not following the protocol
(CalDAV). These should probably be fixed. The other type is where
the client is doing something wrong, where the client is not
following protocol. The question then becomes do we add in some
hacks to the server to support clients who don't follow the
protocol 100%.
Hi Randy,
That's a useful way of framing the bugs. What I'm trying to
understand is what scenarios do we need to support given our 1.0
product goals, independent of who's the source of the problem
(Chandler Server or other clients). Ofcourse, if something is just
simply out of our control (iCal 3 collection creation bug), then we
can't do anything about it other than pester those responsible :)
Which clients do we care most about? It seems like iCal (3?) and
Lightening are the most likely candidates.
What usage scenarios do we care most about?
+ Desktop user shares with iCal/Lightening user
+ iCal/Lightening user shares with Desktop user
+ iCal/Lightening user just syncing with Hub for backup and remote
access via web UI.
+ iCal/Lightening user shares with other iCal/Lightening users?
2. Are we missing data? Is there data you see in iCal, but don't
see in the web UI? Are we talking entire events or metadata of
event items? How critical, universally used is the missing data?
Everyone finds event start-time useful. Not everyone finds task
due dates useful. Very few people find event status useful.
For example, one of the bugs is that cosmo exports 100% valid
icalendar, but for some reason iCal doesn't like how we serialize
EXDATE values. Other clients have no problem because its valid
icalendar, but iCal expects EXDATEs to be serialized in a specific
way. The result is that if you create an EXDATE using the webui or
the desktop, its not visible to iCal users. The reverse is not
true. There was a similar bug that was actually fixed where iCal
didn't like VALUE=DATE-TIME, which is also 100% correct icalendar.
We can tailor the icalendar that we export so that iCal likes it,
but what about other clients? What happens when we export
something that iCal likes, but another client doesn't.
This sounds problematic, but it's not terribly common. Meaning, it
doesn't affect every event, or every recurring series. Just when you
happen to delete an occurrence from a recurring series. Still, I
would nominate this for the q because it compromises Chandler-iCal/
Lightening collaboration, but maybe not at the top of the q...after
all the security stuff, web widget and web UI experience changes?
Fixing this problem for iCal at the expense of other clients might be
a worthwhile trade-off, given the # of iCal users we have syncing
with Hub as compared to other clients.
4. How common are these scenarios? Every iCal/Lightening user will
notice this. One person has reported it.
At least for the above case, its going to happen every time a
desktop/webui/widget user collaborates with an iCal user and the
events being updated involve EXDATEs.
iCal3 Interop :: Creating a calendar causes iCal to mark the
CalDAV account offline
- this is really an iCal bug, no? To 'fix' this on our end, we'd
have to implement scheduling, which we're not planning on doing
any time soon.
- There is awkward workaround for this, which is to create all
calendars on Hub, instead of from iCal.
- Nominate for Future
Since I don't have iCal3, i don't know much about this one.
I think this one is just out of our hands, unless we decide to
implement scheduling. Does anyone know?
iCal not seeing tasks
- Well all items in Chandler are now tasks more or less. So we
could sync all non-event items so that they appear as Tasks in
CalDAV clients. This would also provide a way for us to leverage
iSync to get Chandler data onto mobile devices
- Nominate for Future
The server currently support exporting tasks as VTODOs, but support
is limited and needs work. For instance, once a task is stamped as
an event, it becomes an event. There was some discussion on the
list about this, but I agree we should push this for now.
Yup
Evolution using CalDAV plugin fails to sync with Cosmo and fails
to create events
- Depends on what clients we decide to target
Evolution's CalDAV support has been pretty poor so far. I need to
check if anything has changed.
Ok
-Randy
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
