[Freeipa-devel] Other issues with HBAC calendar

[Simo Sorce]

On Wed, 24 Nov 2010 13:12:02 -0500
Dmitri Pal <dpal at redhat.com> wrote:

> Simo Sorce wrote:
> > On Wed, 24 Nov 2010 11:26:05 -0500
> > Dmitri Pal <dpal at redhat.com> wrote:
> >
> >   
> >> 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.
> >>     
> >
> > May not be the best but it is perfectly reasonable.
> >
> >   
> >> 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 think this is not reasonable at all, it is an arbitrary limit due
> > to the "current" thinking around the UI, if you change mind about
> > the UI tomorrow, you will be left with the constraint in the
> > grammar. This is just backwards.
> >
> > Simo.
> >
> >   
> Keeping in mind that we have just one shot at it, it is unreasonable
> to think that the limitations that the UI imposes will ever go away.

They changed many times since we started and will keep changing in
time, I have no doubt about that.

> Effectively what you and Steven say is that the grammar should dictate
> the UI. It is the wrong approach. As well as the vice versa. The UI
> should not dictate the grammar.

No, what we say is that the UI is the flexible actor in this dram, the
grammar is not flexible.

The worst case for the UI is that it may have to display an ugly rule
in raw grammar.
The worst case for the grammar is that you cannot express a rule, and
have to change it.

> However the grammar also should not have constructs that would never
> be expressed in UI because they are already identified as unusable.

The grammar needs to be flaxible in what can be represented, the UI
then can choose to allow only a subset to be set. The UI drives the
game, the cases where an admin will try to change something at a low
level via direct ldap calls is going to be rare, and in those cases the
UI can very well degrade to a less than ideal mode and show raw rules,
with the option to wipe them out and let the admin replace them with
UI-friendly rules.

> In other words the UI can be subset of what grammar supports but
> all the options that grammar supports should be potentially
> implementable in UI and usable.

Everything is potentially implementable.

> If the they never can be implemented in UI in usable way they
> should not be in grammar.

Given that in the worst case you show a rule by simply describing it in
pseudo-natural language I think the UI has no real limits except the
limits set forth by the specific implementation.

That said I am starting thing that having a grammar that is powerful
enough to express all possible combinations an admin can think of is
not possible to get done right w/o making it extremely complicated.

I need to think a bit more but I think we may want to radically
simplify the grammar instead by splitting single rules (as seen in the
UI) in multiple values. And use additional attributes to aid the UI,
like having a displayTZ attribute that tells the UI what is the
preferred timezone to look at a rule.

Simo.



-- 
Simo Sorce * Red Hat, Inc * New York