cupsPrintFile() has no streaming equivalent?
Michael Sweet
mike at easysw.com
Thu Feb 22 13:20:18 PST 2007
mike wrote:
> ...
> Should convenience functions for printing streams allow
> overriding *http?
Given the history of the API, my inclination is that all new
convenience functions need to take a http_t *, with NULL meaning
"use the default connection".
> rough draft:
>
> int /* O - Job ID */
> cupsPrintStream(http_t *http, /* I - HTTP connection */
> const char *name, /* I - Printer/class name*/
> char *buf, /* I - buffer */
> int len, /* I - buffer length */
> int (*fp)(void *), /* I - function pointer */
> const char *title, /* I - Title of job */
> int num_options, /* I - Number of options */
> cups_option_t *options) /* I - Options */
>
> this one could have two operating modes: direct and loop.
> with direct, you pass buf, len is > 0, and fp is NULL. it just
> takes the buffer and runs with it. in the other mode, fp is not
> NULL and len is ignored. fp() is repeatedly called until it
> returns 0 (or -1, indicating error), accumulating the contents of
> buf into its own buffer by using the return value as the indication
> of number of bytes in the buffer to pull.
> ...
I'm not keen on combining multiple behaviors in a single function -
we should either use the buffer or the callback.
Also, I'm not sure how useful printing a single buffer will be,
but I'm sure there are use cases...
PAPI has a streaming interface that works like an open(), write(),
and close() sequence. If we provided that kind of streaming
interface, it would be simple to write a single buffer, call
a function that writes repeatedly, and/or copy data from a file
descriptor.
Thoughts?
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
More information about the cups
mailing list