Our philosophy with installable options is that an end user can install them any time he/she wants, even way after the shipment and installation of the driver itself.
Jim Sommer from Granite Systems has done some sample implementation under Windows to check out how the current design could work.
We have learnt from it and propose some changes.
Please download the latest dtd files from
ftp://ftp.pwg.org/pub/pwg/upd/Current_Version/DTD/
The proposal explained in this email is not implemented there.
For easier detection, which feature are under discussion or development we have added a 'TBD_' prefix to them, as I indicated few days ago. 'TBD_Connectors' is one of them.
We have noticed that current user interfaces, especially the Configure tab, are designed in a way, which is closely related to these connectors. Almost every UI control represents one connector.
We are thinking about taking over that approach in our concept. This allows us to specify a technical term per connector. As I don't know much about them, in our mother sample it will be a common description what it's for. Can be edited later.
We can give it a name, which will work as the label for that connector.
By that method we can ensure that a connector can only be used once without the need of specifying interdependencies. I hope this will as well automatically solve conditions like 'install tray 3 before you can install tray 4'.
This sample shows that installable options can have own connectors as well to chain trays.
At least for a while we will ignore connectors for SIMM or DIMM. You see RAM handled under print features. We know it is technically not perfect. But it's reality. Nobody differenciates different RAM slots so far. And we'll wait what a specification of those slots will be required for.
See the ExtendedMemory and ROM elements disappear soon in TBD_Connectors.
As a consequence thereof we have to rethink the device and option configuration dtd files.
We are listing a category there. I think this category just goes away in both configurations.
The option configuration is showing a 'Device_Description_Reference' attribute per MasterUnit. We will add a second attribute 'Connector'.
Normally this 'Connector' attribute would be sufficient to specify, where an option can be added to. But we want to avoid errors because of the same name in the technical term attribute in the device description of two different models, where the connectors are not compatible. That's why we want the device description reference as an additional insurance.
In the new device configurations we either specify which of the connectors of a unit are used (my favorite) or we tell to which connector an installable option connects to (unit name and connector).
Feedback requested.
The way we are dealing with installable options is quite unique and very open to third party developers. If you have a proper contact to a third party developer, I'd appreciate, if you'd bring them in.
From now on I'd like us to address the whole feature of dealing with installable options under the term of 'Extensible Configurations' in the public. I'd like to see this established as another keyword next to the four pillars of UPDF (Parameter Converter, Constraints/Interdependencies, Composite Features and EventHandlers).
Regards
Norbert Schade
Principle Software Engineer
Host Software Group
Oak Technology, Inc.
10 Presidential Way
Woburn, MA 01801
USA
Phone: 1-781-638-7614
Fax: 1-781-638-7555
email: norbertschade@oaktech.com
This archive was generated by hypermail 2b29 : Mon Jun 18 2001 - 11:14:55 EDT