On 04/29/2015 11:19 AM, Kenneth Wimer wrote:
Hi all,
I'm on the list now, so no more need to put me in CC...sorry for that, I know that it gets annoying :-(
I think that in general we need to differentiate between the main functions of the UI (starting and stopping services during run-time and configuring the starting and stopping services at boot.) and the various options around those functions.
I agree the module is typically used for 2 use cases: controlling the status (which includes firewall and all that) and configuring the service. I'm not so sure, nevertheless, that the first one deserves to be called primary. I guess some users see the module just as a configuration tool and use the services YaST module or even command line to start/stop and enable/disable. That's what I would expect from server's sysadmins. I guess some users only run the module once in a while to start/stop the service without tweaking the configuration. That's what I would expect in computers that are actually not servers, but can need the service active for a particular purpose during a particular time frame. I also can imagine we everything in between, as usual with YaST.
It seems (correct me if I am wrong, this is just a guess) that the firewall option was added to this UI to accommodate the primary use-case, or most common user path: starting service and then unblocking the port for the service to actually work.
Most likely, yes.
The rest of the UI however, seems like a toolkit of functions and all their possible options and related functions. The first question I would ask would be: Do we want to make a UI which makes it easy for a user to accomplish the primary and secondary use-cases or do we want to present a toolkit with all possible functions and options.
Mixing these options means more work over the long-run...building a UI that is a toolkit for all possible functions and options AND adding bits here and there to represent the most common user paths. I guess it all comes down to out target users, and I'd assume that we currently have little or no solid information on them.
Actually we don't have that information, but even though it makes sense to me to group all the things related to the so-called "primary" use case into one initial screen.
I won't go into the details about LDAP or such because I think we need to answer these bigger questions first.
Those were my 2 cents.
On 29/04/15 08:30, Lukas Ocilka wrote:
On 28.4.2015 22:50, Christian Boltz wrote:
I don't know much about bind, but I'm slightly surprised about the "[ ] LDAP Support Active" option - why is this option on the same tab as the start now/on boot settings?
I'd guess "LDAP Support Active" is a config option for bind, and therefore should be on another tab (maybe "Basic Options"?) It's a generic Bind option to store records in LDAP. Well, we could label then checkbox "Store DNS Records in LDAP" then, that's true.
But we didn't have any "general options" and for that reason, we just put it next to firewall and named service.
To sum it up - I'd take option B with the "LDAP Support Active" option moved to another tab. And I'd propose to use _exactly_ that screen for all services. I'd actually move LDAP + Firewall to some other tab as services start/enable belong to each other from my POV.
If you think option B has too much on one page, move the firewall settings to a separate "Firewall" tab. That's still better than option A ;-) (and if a service needs multiple independent ports (for example, 80 and 443 for Apache), you even have some room for more checkboxes) This is not needed. There will always be just one checkbox for all ports at once. Yast always enables a service defined in /etc/sysconfig/SuSEfirewall2.d/services/ instead of opening/closing ports in firewall. See http://kobliha-suse.blogspot.cz/2008/06/firewall-services-defined-by-package...
(sorry for the advert).
Bye Lukas
-- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org