See in-line also...
Mimi Yin wrote:
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.
What I mean is that an event item doesn't need any external info to be
understood in a non ambiguous way, it's self consistent and doesn't
depend of any data outside itself (e.g. calendar data or user
preference). IOW, it's interpretation doesn't depend of the context in
which it is being read.
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?
Let's look at another scenario: what if I assign PST to my Cosmo account
and EST to Chandler and the sharee is in Paris/France Time? Well, in
that case, the events will show at the time they are supposed to happen
in their respective timezone. You'll certainly say that, in that case,
users turned TZ on and know what they are doing.
OK so the problem we have is only because of the default case (when TZ
is turned off) which is floating. The naive user of your example is
expecting (if I understand your point) to see the event she created to
be created with the "right" (i.e. system) TZ, she doesn't expect
Floating TZ to even exist (she might be naive but she knows the Earth is
not flat and that, by default, an 8am SF event does not happen at 8am in
New York).
The problem then is that our default is wrong. In which case, I think we
should change the default (have a default that is the one expected by
users, i.e. use the system TZ as default when TZ has not been turned on)
rather than create an inter-app Cosmo/Chandler protocol to patch the
problem.
Cheers,
- Philippe
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
