From: Norm Jacobs <Norm.Jacobs@Sun.COM>
To: Cherif YAYA <chef.ya@gmail.com>
Cc: printing-architecture@lists.linux-foundation.org
Subject: Re: [Printing-architecture] Summer of Code PAPI project
Date: Thu, 27 Mar 2008 22:52:32 -0500 [thread overview]
Message-ID: <47EC6B80.9090407@Sun.COM> (raw)
In-Reply-To: <e942fc210803241856u1da4d98by5c035557ef462e78@mail.gmail.com>
The libpapi-cups code that you found in the papi tarball was originally
written by Alan Hlava at IBM. He wrote it as a prototype against an
earlier draft of the PAPI (pre v0.92 I think). It is probably pretty
close to what's in the PAPI spec, but I don't know for certain. The
extent of my experience with it was a fairly quick review of it and some
porting work to make it build against libcups.
My recollection of the history of the libpapi-cups code is that it was
written by Alan Hlava at IBM as a proof of concept of PAPI prior to the
v0.92 draft of the API. He wrote it to build against the a version of
the libcups http and ipp interfaces that were split out from libcups.
The extent of my experience with that particular code was a fairly quick
review of it and some porting work to make it build against libcups (not
his broken out subset). I have some vaque recollection that it used
some libcups interfaces that would pose problems handling multiple
papi_service_t service contexts in the long run.
The most recent PAPI code in the sourceforge openprinting project's SVN
repository includes a complete PAPI over IPP implementation that works
with CUPS IPP service. That being said, one of the things that has been
discussed several times in the OpenPrinting Workgroup is the desire to
build a PAPI implementation that would integrate into the CUPS code
base. While the PAPI over IPP implementation works with CUPS, it
probably wouldn't be exactly what I would integrate into the CUPS code
base if I were doing so. A version that were to integrate into the CUPS
code base would probably want to
* leverage some of the building blocks in the libcups interfaces
(aside from the http and ipp interfaces).
* avoid using a portion of the CUPS convenience interfaces
* maintain CUPS http and ipp constructs per papi_service_t object.
Another thing that is very important to cover here is unit testing of
the various interfaces.
-Norm
Cherif YAYA wrote:
> Till, Ira,
> Thanks a lot for your answers.
> I'm looking forward to hearing from Norm and Wendy. Particularly about
> the progress status of the existing implementation.
>
> Cherif
>
>
> 2008/3/23, Ira McDonald <blueroofmusic@gmail.com
> <mailto:blueroofmusic@gmail.com>>:
>
> Hi Norm and Wendy,
>
> Could one of you answer Cherif's questions below, please?
>
> Thanks very much,
> - Ira
>
> --
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music/High North Inc
> email: blueroofmusic@gmail.com <mailto:blueroofmusic@gmail.com>
> winter:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> summer:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>
>
>
> On Sat, Mar 22, 2008 at 8:09 PM, Till Kamppeter
> <till.kamppeter@gmail.com <mailto:till.kamppeter@gmail.com>> wrote:
> > Cherif YAYA wrote:
> > > Also in the TODO file, under the libpapi-cups entry it is
> said that
> > > "Once libpapi-ipp is complete this can be dropped, because
> CUPS will
> > > accept jobs from "any" IPP client and the PAPI IPP support is
> guaranteed
> > > to work." Does that mean that any work done for this project
> would be
> > > practically useless? It's probably not the case and I'm
> probably missing
> > > something. But I'd like some clarification as to how the
> deliverables of
> > > this CUPS integration will contribute to the PAPI effort.
> >
> > For me this looks more like that libpapi-cups' functionality
> gets merged
> > into libpapi-ipp. Norm, Wendy, am I correct?
> >
> >
> >
> > Till
> >
>
> > _______________________________________________
> > Printing-architecture mailing list
> > Printing-architecture@lists.linux-foundation.org
> <mailto:Printing-architecture@lists.linux-foundation.org>
> > https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
> >
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
>
next prev parent reply other threads:[~2008-03-28 3:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-22 22:58 [Printing-architecture] Summer of Code PAPI project Cherif YAYA
2008-03-22 23:31 ` Till Kamppeter
2008-03-23 0:09 ` Till Kamppeter
2008-03-23 16:46 ` Ira McDonald
2008-03-25 1:56 ` Cherif YAYA
2008-03-28 3:52 ` Norm Jacobs [this message]
2008-03-28 20:29 ` Till Kamppeter
2008-03-30 1:49 ` Cherif YAYA
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47EC6B80.9090407@Sun.COM \
--to=norm.jacobs@sun.com \
--cc=chef.ya@gmail.com \
--cc=printing-architecture@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.