Hi,
During the conversation with Ben and Kyle today over the calendar screen two things came up: 1) Time zone 2) Duration
Time zone
It makes perfect sense to allow the admin to enter the rule and specify the time zone that the admin used to enter the time. Internally it will be converted to UTC but for the purpose of easier rule creation specifying time zone is helpful. Our grammar right now does not allow saving the zone since we plan to convert time to UTC, however when the value is fetched from the LDAP and presented for editing it is unclear which time zone it was entered in. Also there are two approaches to dealing with time zone information in general. Imagine you have a drop down with time zones. Imagine you entered time and then change the selected time zone in the drop down. Should the time you entered be automatically adjusted? First approach says "yes" but that means that we will have to implement a complex time recalculator since in corner cases the time difference between the time zones will affect the starting. The second option is to say: the time zone is just a specifier for the whole time rule indicating that the time values were entered in the given time zone. The when you change the value of the time zone you do not recalculate anything. With the right UI structure this can be made more obvious. However when the value fetched from the LDAP and displayed it might be useful to recalculate so I see two options how we can deal with the time zones. a) Do not save the time zone but recalculate the time (and date ???) when you change time zone in the drop down both in add and edit cases. When you fetch and display always use UTC but allow admin to change the "timezone view" at his will. b) Save time zone in the rule. As Simo pointed the time zone definition change from time to time so it makes sense to actually save offset and timezone as additional hint. This way we can easily convert the time stamp into the specified time zone and back at save and retrieval with no need to implement complex logic in the UI.
IMO the second option is simpler but requires yet another change to grammar. I suggest we add offset and time zone as optional fields somewhere at the end of the rule or after start time.
Duration
New grammar allows DDHHMM for the duration. UI proposes to limit the duration to less than 24 hours since more than 24 hour windows can start overlapping and thus allowing to enter duration days was confusing to the users who tried the UI. We need to reconcile this a bit between what can be stored and what can be displayed. IMO it makes sense to allow windows more than 24 hours (regular service window over weekend for example). But on the other hand I see how having a separate field for number of duration days in the UI might be confusing. I would vote for not having days in the UI at all but allowing any numeric value to be entered into the hours field. This however rises a question whether we want to have the duration be in DDHHMM format in grammar or in just NMM format where N is any numeric value that represents unlimited number of hours. Thoughts?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/22/2010 10:54 PM, Dmitri Pal wrote:
Hi,
During the conversation with Ben and Kyle today over the calendar screen two things came up:
- Time zone
- Duration
Time zone
<snip>
Time zone should always be entered relative to the server, not the user entering it. This should be clearly identified in the UI. Then there's no ambiguity upon reading it back out, as it is ALWAYS relative to the server.
Duration
New grammar allows DDHHMM for the duration. UI proposes to limit the duration to less than 24 hours since more than 24 hour windows can start overlapping and thus allowing to enter duration days was confusing to the users who tried the UI. We need to reconcile this a bit between what can be stored and what can be displayed. IMO it makes sense to allow windows more than 24 hours (regular service window over weekend for example). But on the other hand I see how having a separate field for number of duration days in the UI might be confusing. I would vote for not having days in the UI at all but allowing any numeric value to be entered into the hours field. This however rises a question whether we want to have the duration be in DDHHMM format in grammar or in just NMM format where N is any numeric value that represents unlimited number of hours. Thoughts?
I agree that we don't want to have > 24 hours in the UI.
DDHHMM is easier to parse, and I can't come up with an example where a window of longer than 99 days makes sense. Instead, it should be a recurring event.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/22/2010 10:54 PM, Dmitri Pal wrote:
Hi,
During the conversation with Ben and Kyle today over the calendar screen two things came up:
- Time zone
- Duration
Time zone
<snip>
Time zone should always be entered relative to the server, not the user entering it. This should be clearly identified in the UI. Then there's no ambiguity upon reading it back out, as it is ALWAYS relative to the server.
I don't want to throw a wrench in, but what if you have multiple replicas in various distant locations, WHICH server is the time relative to?
rob
Duration
New grammar allows DDHHMM for the duration. UI proposes to limit the duration to less than 24 hours since more than 24 hour windows can start overlapping and thus allowing to enter duration days was confusing to the users who tried the UI. We need to reconcile this a bit between what can be stored and what can be displayed. IMO it makes sense to allow windows more than 24 hours (regular service window over weekend for example). But on the other hand I see how having a separate field for number of duration days in the UI might be confusing. I would vote for not having days in the UI at all but allowing any numeric value to be entered into the hours field. This however rises a question whether we want to have the duration be in DDHHMM format in grammar or in just NMM format where N is any numeric value that represents unlimited number of hours. Thoughts?
I agree that we don't want to have> 24 hours in the UI.
DDHHMM is easier to parse, and I can't come up with an example where a window of longer than 99 days makes sense. Instead, it should be a recurring event.
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkzr4WkACgkQeiVVYja6o6PmXgCbBKNR3qb5uh2hJlfF1TsQLkMz yx4AnAuGm/PADzU9CFa2+DRCmLbDxq1k =7+wV -----END PGP SIGNATURE-----
Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Duration
New grammar allows DDHHMM for the duration. UI proposes to limit the duration to less than 24 hours since more than 24 hour windows can start overlapping and thus allowing to enter duration days was confusing to the users who tried the UI. We need to reconcile this a bit between what can be stored and what can be displayed. IMO it makes sense to allow windows more than 24 hours (regular service window over weekend for example). But on the other hand I see how having a separate field for number of duration days in the UI might be confusing. I would vote for not having days in the UI at all but allowing any numeric value to be entered into the hours field. This however rises a question whether we want to have the duration be in DDHHMM format in grammar or in just NMM format where N is any numeric value that represents unlimited number of hours. Thoughts?
I agree that we don't want to have > 24 hours in the UI.
DDHHMM is easier to parse, and I can't come up with an example where a window of longer than 99 days makes sense. Instead, it should be a recurring event.
Steven, please think about the case when the rule needs to be edited in UI and it has some value for DD - say 1. What you display in UI then? If you do not allow to enter days and you not allow more than 24 hours in the hour field you will fail to translate the rule to the proposed UI. The only option would be to show the raw rule in this case. IMO this does not seem like the best option to me. I think the DD is redundant and other means should be used to schedule windows bigger than 2 days however the HH should IMO allow 1-48 ours to allow specifying a week end outage like: from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to ask to split the rule into several slices.
_______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/24/2010 11:26 AM, Dmitri Pal wrote:
Duration
New grammar allows DDHHMM for the duration. UI proposes to limit the duration to less than 24 hours since more than 24 hour windows can start overlapping and thus allowing to enter duration days was confusing to the users who tried the UI. We need to reconcile this a bit between what can be stored and what can be displayed. IMO it makes sense to allow windows more than 24 hours (regular service window over weekend for example). But on the other hand I see how having a separate field for number of duration days in the UI might be confusing. I would vote for not having days in the UI at all but allowing any numeric value to be entered into the hours field. This however rises a question whether we want to have the duration be in DDHHMM format in grammar or in just NMM format where N is any numeric value that represents unlimited number of hours. Thoughts?
I agree that we don't want to have > 24 hours in the UI.
DDHHMM is easier to parse, and I can't come up with an example where a window of longer than 99 days makes sense. Instead, it should be a recurring event.
Steven, please think about the case when the rule needs to be edited in UI and it has some value for DD - say 1. What you display in UI then? If you do not allow to enter days and you not allow more than 24 hours in the hour field you will fail to translate the rule to the proposed UI. The only option would be to show the raw rule in this case. IMO this does not seem like the best option to me. I think the DD is redundant and other means should be used to schedule windows bigger than 2 days however the HH should IMO allow 1-48 ours to allow specifying a week end outage like: from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to ask to split the rule into several slices.
I don't want the internal representation to have arbitrary limitations set by the WebUI. It's trivial for the WebUI to be designed to convert hours to days and reverse. So we can store it in DDHHMM format and display it in the WebUI as hours if we really want to.
To someone writing a rule by hand, the DDHHMM representation is going to be far more useful.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Stephen Gallagher wrote:
On 11/24/2010 11:26 AM, Dmitri Pal wrote:
Duration New grammar allows DDHHMM for the duration. UI proposes to limit the duration to less than 24 hours since more than 24 hour windows can
start
overlapping and thus allowing to enter duration days was confusing to the users who tried the UI. We need to reconcile this a bit between what can be stored and what can be displayed. IMO it makes sense to allow windows more than 24 hours (regular service window over weekend for example). But on the other hand I see how having a separate field for number of duration days in the UI might be confusing. I would vote for not having days in the UI at all but allowing any numeric value to be entered into the hours field. This however rises a question whether we want to have the duration be in DDHHMM format in grammar or in just NMM format where N is any numeric value that represents unlimited
number
of hours. Thoughts?
I agree that we don't want to have > 24 hours in the UI.
DDHHMM is easier to parse, and I can't come up with an example where a window of longer than 99 days makes sense. Instead, it should be a recurring event.
Steven, please think about the case when the rule needs to be edited in UI and it has some value for DD - say 1. What you display in UI then? If you do not allow to enter days and you not allow more than 24 hours in the hour field you will fail to translate the rule to the proposed UI. The only option would be to show the raw rule in this case. IMO this does not seem like the best option to me. I think the DD is redundant and other means should be used to schedule windows bigger than 2 days however the HH should IMO allow 1-48 ours to allow specifying a week end outage like: from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to ask to split the rule into several slices.
I don't want the internal representation to have arbitrary limitations set by the WebUI. It's trivial for the WebUI to be designed to convert hours to days and reverse. So we can store it in DDHHMM format and display it in the WebUI as hours if we really want to.
Sorry but you are completely wrong here. First this is not an arbitrarily limitation but a usability one. Second it is not trivial to design web UI especially to be usable. Current version of the proposed UI (I hope you have seen it) says: a) No day field b) Hours field can't accept more than 24 hours You agreed in the first email that these are reasonable UI limitations. So IMO it is completely unreasonable to store something that we can't ever represent in the UI (not because we do not have time, but because the internal grammar contradicts the suggested UI).
I see three outcomes in current situation: 1) Allow schema to have DDHHMM as you proposed and have UI as Ben proposed and close eyes to all the ugliness it creates. IMO it is just wrong and will backfire in future. 2) Adjust UI to match proposed schema - this means we should either add a day field in the UI or allow the time field to store more than 24 hours 3) Adjust the schema to match the UI - IMO this is the path of least resistance and most reasonable thing to do.
So to summarize I disagree and stick to my point. Please get together with Ben on Monday and come to consensus on 2) or 3). I do not care. 1) Is not an option.
To someone writing a rule by hand, the DDHHMM representation is going to be far more useful.
_______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
sssd-devel@lists.fedorahosted.org
-
Dmitri Pal -
Rob Crittenden -
Stephen Gallagher