As I've said before, I think it quite unlikely that this would ever be used by the CUPS server, but Michael Sweet would be the one with the answer to that.
In any case, whether a particular library does or does not use glib is only visible in terms of the dependencies pulled in. The end result would include an XML parser, of course, so glib is hardly the final straw when it comes to added dependencies!
Ok, so let's forget about cups server for now.
Well, CUPS has no inherent notion of there being different models of printer. It only knows about different PPDs. A given PPD can declare its manufacturer (this is exposed by CUPS in the ppd-make attribute), and its "nickname", i.e. a combination of the model name, possibly including the manufacturer's name, and the driver used, often as well as other bits of information. This is exposed by CUPS in the ppd-make-and-model attribute.
This is why cupshelpers.ppds has a fairly expensive ppdMakeModelSplit() function: in order to collect together PPDs which are for the same physical printer model.
Ok please look at this file: http://websvn.kde.org/trunk/playground/base/print-manager/libqcups/PPDModel....
Are you saying that I can't trust on ppd-make string to have the manufacturer? I can filter all my ppds by it's make without running any expensive task, if you can install kdelibs-devel and qt4-devel you can try my code to see how the ppd choser works now.
Well first to get the devices (done by qcups) and then to get the ppds list (done by pppds.py).
Ah. But cupshelpers.ppds doesn't interact with the CUPS service at all. It only processes an IPP result. Think of the PPDs object as the representation of a set of PPDs, and the actions you'd like to perform with them.
See this is the problem, how would you get an ippResult that I got with my bindings? Imagine this, if you can make ppds.py have a cmd line interface and that it does not talk with the cups server then I think this would be the easiest/maybe best solution. (though it would be harder for me to help on ppds.py due to py)
What I see in master is both ppds.py and the xml.py thing so I didn't knew ppds.py was deprecated.
No, ppds.py is not deprecated, but the interface it provides is substantially different. The "old" interface gave only one PPD, the "best", when matching a Device ID; the "new" interface gives an ordered list of all the appropriate drivers, in descending order of preference. This allows the interface to present choices based on the Device ID from the printer, something that allows the user to be more sure of getting their printer to work.
For example, if a particular printer is driven by gutenprint (and gutenprint declares the Device ID of that printer in its PPD), the "best" printer driver might be gutenprint. But if that driver doesn't work, the user has to look for other drivers. There may only be generic drivers as alternatives, and we can only offer those based on the Device ID's "CMD" field.
Right I think it's important for the user to pick a good alternative.
Another important change is that instead of having a status code to describe how well the driver matches to the printer, now a string is used, the "fit", e.g. "exact-cmd" (meaning that the model name matches exactly, and the CMD field positively matches the declared command sets of the PPD), "exact" (meaning just that model name matches), etc. This provides more information than the status codes.
Sure that's good, though I think maybe a percentage value would be nice, so we could display a set of stars.
I'm not sure I follow you. The pycups project is separate from system-config-printer. They are separate tarballs, and have quite distinct aims.
Ok I thought they were basically the same thing.
What would be the point of having a forked CUPS project with this extra IPP operation? It could not be relied upon by anyone, since they would need to be compatible with the "real" CUPS project as well.
Which "downstream" are you thinking of, in any case?
Ok, good point, I think an ipp operation is only good when upstreams accepts, otherwise we will have a non compliant server. But by downstream we can still pacth the cgi part to use the features of best guessing the ppd which wouldn't make the server different.
Daniel.