attachment-0001

<html> <blockquote type=cite cite>From: <a href="mailto:norbertschade@oaktech.com">Norbert Schade</a> To: <a href="mailto:upd@pwg.org">UPD group</a> 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: <a href="mailto:norbertschade@oaktech.com">norbertschade@oaktech.com</a></blockquote> <div><a href="mailto:sommer@granitesystems.com" EUDORA=AUTOURL>mailto:sommer@granitesystems.com</a></div> <div>978-486-3068</div> </html>