Lisa Dusseault wrote:
What do people think about using a client/server protocol
to get calendar data to the Palm/mobile device?
I think this question can be answered with the right research into how
our target users are using devices.. I guess what I have in my mind is
that back when I was a Palm user (some 4+ years ago) you were still
tied to a PC to do sync, but I'm sure a lot of that has changed. My mom
(yes, another "my mom..." reference) is fairly non-technical and just
bought a new palm pilot (I couldn't convince her how cool the Treo was
:)) and tells me it still does syncing via a cable to her desktop...
Now obviously, my mom is not the target user, but I was actually
surprised that modern devices were still syncing this way.
So for those of you (the more power users) actively using devices: How
do you currently "sync" - a cable or bluetooth to a PC? Do "most"
devices out there have WiFi? Do they go through cell providers and just
talk to a server over IP?
My take is that we shouldn't do any device-specific work - i.e. writing
any software that is actually running on devices themselves, because
that's a huge undertaking... but perhaps there are some windows, mac
and linux-specific ways to just implement a "conduit" (if that's what
they're still called) to make devices talk to chandler and/or cosmo?
Then we could at least go after the biggest market (Windows) for now
and see how people like it? But this is all just based on me making
assumptions about how devices are talking to things these days.
Alec
- It's the only usable approach for email -- I know
people who love their IMAP or POP clients for treo or Palm, and I don't
think PC synch is even an option here
- Contacts are feasible as a PC synch approach because contacts data
is relatively static
- Calendaring is somewhere between the volatility of email and
stability of contacts, but... in a world where more people are moving
their calendar data to a server, isn't PC synch going to feel awfully
clumsy?
I know I'm showing my biases here, but even trying to discount those, I
still think this is the future for mobile calendaring.
Lisa
On Nov 30, 2005, at 7:11 PM, Heikki Toivonen wrote:
Ted Leung wrote:
Lack of a PDA story makes us a non-starter
for a lot of people. The
problem is that there is probably no good cross platform way to do
this. It seems to me that the shortest path involves seeing if we
could write import/export plugins that could talk to platform native
services (such as Sync Services on OS X) which already know how to talk
to PDAs.
There are some PDA products (well, PDA platforms) with significant
market share and we could target one or two popular ones to get
started.
Writing something for a platform specific service could also be an
option.
A quick search on SyncML showed that there are 14 projects on
sourceforge.net that mention it. Google search gives many more.
Brian Skinner did some research on SyncML for OSAF a couple of years
ago: http://wiki.osafoundation.org/bin/view/Projects/SyncML
I bet the situation has changed a lot since then.
I didn't see ACL's in the infrastructure
tenet. Unless they are in
there to support 0.7 sharing functionality (or the work needs to start
now in order to be ready for 0.8), then I think we should defer.
I think it should be a conditional item: if Cosmo is going to get ACL
in
time for Chandler 0.7 I think we should invest in it in Chandler as
well. I have an ACL library in Zanshin where the implementation is
maybe
80% complete of what I think we would need for 0.7, which IMO basically
means an API that semi-automatically translates a standard ACL to
server-customized ACL and vice versa.
--
Heikki Toivonen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design