Hi Philippe,
See in-line...
On Dec 12, 2006, at 2:17 PM, Philippe Bossut wrote:
Mimi Yin wrote:
I think this might be problematic. If you're a Chandler user who
is getting a Cosmo account to use the Hosted Service (as opposed
to using the Cosmo UI), you might think you're setting time zone
preferences for Chandler. Indeed, what would it even mean to have
timezones turn on in Cosmo, but not in Chandler?
I think we need to keep these in sync.
I don't think so. The TZ in Chandler is a "display" and "use as
default" thing. Once events are created, the TZ is stored with them
and moved with them. It's context independent at that point and
should stay that way.
Could you give an example to illustrate what you mean by context
independent? I'm not sure I understand.
I'd be worried if something made on a Cosmo account would require
changes on a Chandler install. What if Chandler is off line and
modifs done by the user? Besides, it assumes a 1:1 relationship
between Chandler installs and Cosmo accounts while you can have
several Cosmo accounts used from one Chandler install (not right
now though but there's no reason to preclude this) and several
Chandler installs pointing to the same Cosmo account (and that you
can do now and it can be useful if you have several machines).
I just worry about the following scenario...What if I assign PST to
my Cosmo account and Chandler is still Floating because I haven't
turned timezones on. On the same calendar, the events I create on
Cosmo will be in PST and the events I create in Chandler will be
Floating...and then I share this calendar and the sharee is in EST.
How do we prevent users from getting into this state?
Mimi
Or may be I'm missing something (I need to confess I didn't read in
detail the long long Cosmo TZ saga...).
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
