UPD Mail Archive: UPD> user group policies

UPD Mail Archive: UPD> user group policies

UPD> user group policies

From: Jim Sommer (jsommer@bellatlantic.net)
Date: Thu Oct 04 2001 - 15:13:39 EDT

  • Next message: Jim Sommer: "UPD> Orientation/Rotation"

    >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
    >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
    >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.
    >Norbert Schade
    >Principal Software Engineer
    >Advanced Development / Connectivity
    >Oak Technology, Inc.
    >10 Presidential Way
    >Woburn, MA 01801
    >Phone: 1-781-638-7614
    >Fax: 1-781-638-7555
    >email: <mailto:norbertschade@oaktech.com>norbertschade@oaktech.com


    This archive was generated by hypermail 2b29 : Thu Oct 04 2001 - 15:15:40 EDT