cupsPrintFile() has no streaming equivalent?

[mike]

> 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".

this is the behavior i have moved forward with.

> > int cupsPrintStream(http_t *, const char *, char *, int, int (*)(void *), const char, int, cups_option_t);
>
> > 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.

i wasn't sold on the idea either.  i'll stick with the callback, as it's the most flexible (and lends itself most easily to passing FILE*/fread to implement current functionality).

> 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.

PAPI?

what i've done so far is completely implemented a cupsDoStreamRequest utilizing a simple fp/arg callback and the existing code and then modified cupsDoFileRequest to use cupsDoStreamRequest.  all in all, the amount of code remains relatively the same.  i'm about to revisit util.c and finish up the work i did there (i jumped to request.c when i got down to the cupsDo*Request calls).

i am concerned about not being able to specify the length of the data.  in cups/request.c, lines 160-165, it appears that the Content-Length header is explicitly set from the IPP request header length and the file size as gleaned from stat().  if the data size is required and the request cannot be delayed until all data is read via the callback, we may have to abandon the callback method in favor of a simple buffer and associated length.

-mike