>OK.  Please bear in mind that you'll 

>> also need to convert
>cupshelpers/xmldriverprefs.py as well.

Sure, 

>It would 
>> be great to have this work in progress go in a branch from
>master.  Will 
>> you have your own git repository tracking it, or be
>working in the main 
>> fedoraproject.org git repository?

I think creating this branch is best, though to be honest,
the end of year is a rush, and I'm not sure I'll have time again
to work on this ... kde ppl will kill me :P

>If you do the work as a GObject, Python 
>> bindings will be more or less
>automatic via gir.
>> href="http://live.gnome.org/GObjectIntrospection" target=_blank 
>> >http://live.gnome.org/GObjectIntrospection
The problem here is that GObject means glib which is not used in cups server.

>By converting the entire 
>> thing to C, you'll still need to preserve the
>core methods such as getMakes 
> and getModels.  You don't get them
>automatically from CUPS-Get-PPDs, 
> just a list of ppd-make-and-model
>strings.  In simply providing the 
> other interface methods, these lists
>of makes and models have to be 
> calculated -- hiding them just means the
>work has to be duplicated elsewhere 
> in the program.

well, at least to get all models iirc there is a get method for that,
have to look at admin.c again.

> I think the best thing to do would be to create a 
> method like

> IppResult* getBestPPDForID(char *id, IppResult 
> *resultOfPPDS)
> {
>    this way I can use my QCups class 
> which handles the authentication
>    on cups for me (with DBus 
> the user would have to authenticate twice)
>    then getAllPPDS 
> and pass the cups result to here.
>    Cups server (631) could 
> use this method easily.
>    here there would be the ppd.py 
> code

>Why do you say that D-Bus would require the user to authenticate 
> twice?

Well first to get the devices (done by qcups) and then to get the ppds list (done by pppds.py).


> Also, in C, surely we'd be using real CUPS types such as 
> ipp_t*?

yes cups types it's just that I forgot the name of the type.

>> So what do you think of this? I think it's a good 
>> start,
>> if you can put this lib in py-cups binding we can work
>> 
>> latter on the XML thing that you are working on now.

>I don't see the 
> point in starting with old code.  Why not use what's
>currently in 
> master?  It will be more than double the work if you have
>to redo it, 
> not least because the interface is different.

What I see in master is both ppds.py and the xml.py thing
so I didn't knew ppds.py was deprecated.

>The work belongs in 
> system-config-printer, not in pycups (which is just
>what it says and no 
> more).  There are already exported interfaces in
>system-config-printer 
> such as the Python cupshelpers modules --
>including cupshelpers/ppds.py, 
> which is what we're talking about.

well but in C you could access them through pycups which,
would be the same thing in the end I think.

>How might the C interface 
> look?

well surely you know these methods better that I do,
but I think we can have them all and using the cups types
to make it easy to play with.

>> Having this as a C lib might even be added directly in 
>> CUPS
>> thus maybe having Apple (cups devs) to help too.

>I really 
> don't think that would happen, but you'd have to talk to
>Michael Sweet.  
> Choosing a "best" driver has long been something that
>the CUPS server is 
> neutral on.


Well if it doesn't get accepted by upstream we can patch it
downstream easily I think. It would be pretty handy since
most printing servers I see the admins only use the cups server
interface.

Best,
Daniel.