We are talking for some time about limiting our specification to certain features like media handling, font handling, color, etc., but providing a generic method to add others like EconoMode, REt, etc. I call the latter group of features the generic features from now on for better identification.
We said we would provide a number of fields to make the most entries and probably even prepare different structures for different groups of features (the simple On/Off features, finishing features like stapling/punching with position values, etc).
I must say I suffer.
I admit I suffer for quite a while already.
As much as I like the idea to limit the UPDF to the most common features and have one more generic feature called 'GenericFeature', I don't trust it really.
The more I think about it the more I suffer. And I have this suspicious feeling in my stomach that we oversee something. As some of you know I care alot about my stomach.
Enough joking. I haven't solved all issues around the generic features so far. Either we solve it or they will go or we'll buy some weaknesses.
1. Bidirectional communication
When it comes to bidi, the driver must detect the meaning of a certain incoming feature to make the connection to a driver setting. We haven't talked about bidi too much so far, but even if we leave it out in the first level of UPDF, I want us to anticipate enough functionality that we will not have to change a previous spec when adding new functionality in future.
I have certain expectations of bidi. I do not expect bidi to tell me everything a driver may have or likes to know about a certain feature. It is enough when bidi is telling me what of the information the driver has already (either compiled or as UPDF) is to be activated. As a consequence this may activate a whole group of other information not having been passed in. And that's ok.
So it comes to keywords and settings. Settings can be different things: values, ranges, structures and may be more.
The point when talking about generic features is that the driver must be able to anticipate, which keywords and settings the bidi routine will pass in.
Sample: it must know that the bidi keyword is EconoMode and not EMode. It must know that the setting is a toggle and not one within a range of values.
If we do not care about this anticipation, we let the whole API between a driver and a communication routine open. That would mean we forget about a common API to a communication routine and leave that open to everybody's proprietary solution - which is a legitimate way to go. But I am still dreaming there will be one common IPP communication routine and one common PJL (or whatever) communication routine. That would mean every UPDF would have to anticipate the same keywords and settings.
So if we find a solution for the bidi problem, I feel it must include a spec for predefined keywords and a description how settings can come in. Then a driver can understand incoming parameters.
2. Constraints
I think this is even more serious.
Imagine we generic features and somebody implements two instances of them: EconoMode and REt.
The element name in the dtd would be GenericFeature in both cases. Literally it is not GenericFeature1 and GenericFeature2.
That's the point. The element names are not unique.
How would somebody specify a constraint that EconoMode=On cannot go with REt=On (forget about the nonsense of the statement)?
This constraint issue is going wild in my stomach. This is definitely a showstopper!
Please help me out.
Norbert
This archive was generated by hypermail 2b29 : Thu Mar 22 2001 - 16:46:06 EST