>From: <mailto:norbertschade@oaktech.com>Norbert Schade
>To: <mailto:upd@pwg.org>UPD group
>Sent: Tuesday, October 02, 2001 12:51 PM
>Subject: user group policies
>
>Now that we have solved some bugging items, we can concentrate on the
>future design again.
>I'd like to do an outlook on user group policies that we all together
>become a bit more familiar with it.
>Assuming that normally a developer of the printer manufacturer would write
>the complete set of an UPDF description, the result is a neutral
>description of one specific model.
>A number of users, especially large enterprises, like to go a step further
>and specify some needs for themselves.
>These specifications are normally set by supervisors or administrators.
>They create sets for single users or user groups.
>1. They may like to set user specific defaults differing from the original
>IHV defaults.
>These defaults should become active right during installation of the
>driver/client and should not need any extra step by the user. He/she
>should not even notice it.
>2. Another nice-to-have feature might be to manipulate the complete user
>interface. That could mean either hide certain entries of a UI control,
>hide some controls completely or even create new controls.
>
>This is the area we call user group policies.
>I'm going to make some statements as the first input. Please feel free to
>contradict, change and add. So far we have not specified in detail, which
>of the features we will be able to accomplish in UPDF, and especially in
>UPDF level 1.
>
>Required features
>1. Special defaults.
>2. UI manipulation.
>2.1. Manipulate entries of UI controls.
>2.2. Manipulate the appearance of UI controls.
>2.3. Add new UI controls.
>
>The first question is where do these users get their UPDF description
>from. Normally it may be stored on a storage medium (CD, etc.), on a web
>site or even in the printing device. Only on a storage medium there would
>be the chance for a supervisor to edit files like the device configuration
>xml file to add user group policies.
>So for now we make the assumption that the supervisor will create
>directories per user or user group to hold all files necessary for
>installation.
>We further assume that the supervisor has good to excellent knowledge
>about UPDF and will be responsible for the intended changes. We only can
>provide the structures.
>
>Feature 1
>There is a rather simple solution. When all files are copied somewhere, a
>supervisor can change the locale files and especially the LocaleDefault
>elements. No technical problem.
>Though technically possible we may not recommend to add/remove complete
>locales and make the proper changes in the configuration file.
>As I hate somebody changing the original UPDF files, I'd could imagine
>another approach. The only modifications to the original files should be
>done to the unit configuration xml files (we could prepare that in the
>schemas by adding an optional element, which we and the IHV normally would
>never use). If the optional element for user group policies is present, it
>holds all information the driver needs. May need some thinking. But now
>the supervisor is able to add his own locale references, which hopefully
>have been copied from the original ones first, and refer to anything else
>he/she needs. We need common rules for that.
>
>Feature 2.1
>Hmmm. I'm a little hesitant here. The interdependencies would be the tool
>to allow something like 'if this record of this feature is selected,
>select that record of another feature'. 'hide this record' might be
>something else a supervisor wants to do. We do have an Appearance
>attribute on the feature level, but not one on the record level.
>Add a new record for a feature seems difficult as well. I only can imagine
>this to work with certain composite features like a global driver setting
>control feature. Would be very difficult to specify.
>Additionally I guess that all original interdependencies should still
>work. So a new one should not interfer with any original. That needs some
>concentration, if possible at all in any case.
>
>Feature 2.2
>Making certain UI controls disappear completely from the UI does not seem
>to be such a technical problem.
>I guess the UI dimensions would still be the same. There would just be
>some holes.
>As every feature has a default, they all have an active setting. That rule
>is not broken, when the setting would change in the background by some
>interdependency.
>
>Feature 2.3
>New controls can only be composite features! That's the only instance
>where the driver might be prepared to face controls, which meaning it does
>not understand - and need not.
>The only reasonable control I can think of is a 'User Specific Setting'
>control, set on top of all other controls as a composite feature.
>All entries would have to be handled by the supervisor, of course. We
>would not interfer with any original control.
>There are still a number of questions like the default for this (or these)
>control(s). And should it or they be localized?
>
>Anyhow, whatever UI manipulation we may have in mind, my point is it has
>to be done outside the original UPDF description.
>
>Ok, I wanted to initiate that discussion before San Antonio and show that
>I have some thoughts about it.
>But that's not enough to get it going.
>
>
>Regards
>Norbert Schade
>Principal Software Engineer
>Advanced Development / Connectivity
>Oak Technology, Inc.
>10 Presidential Way
>Woburn, MA 01801
>USA
>Phone: 1-781-638-7614
>Fax: 1-781-638-7555
>email: <mailto:norbertschade@oaktech.com>norbertschade@oaktech.com
mailto:sommer@granitesystems.com
978-486-3068
This archive was generated by hypermail 2b29 : Thu Oct 04 2001 - 15:15:40 EDT