Libxo bugs and fixes.

[Alfred Perlstein]

On Jan 4, 2015, at 2:26 PM, Phil Shafer wrote:

> Alfred Perlstein writes:
>> On 1/3/15 9:05 PM, Phil Shafer wrote:
>>> I dislike using a non-standard function like this.  I'd prefer the
>>> caller flag this information on the handle. There's already a flag
>>> one can set on a handle that will trigger a call to flush data
>>> buffered in the handle to the write function.  I'll add a function
>>> to set a custom flusher, which will be called at appropriate times.
>>> Apps like netstat will know if they need iterative output, and can
>>> decide to set the XOF_FLUSH flag with a flusher callback.  If needed,
>>> that callback can use __flbf.
> 
> We considering this: given that the caller knows when it wants to
> fflush(stdout) and libxo doesn't, it seems we'd be better served
> having the app do something like:
> 
>    for (;;) {
>        xo_open_instance("foo");
>        ...
>        xo_close_instance("foo");
>        xo_flush();     /* Flush data buffersd in libxo */
>        if (__flbf(stdout))
>            fflush(stdout); /* Flush data buffered in stdio */
>    }

That api… could it not be better?  Also, won't it be fully buffered when it's to a pipe to another program?  I think I messed that up.  We probably want actually if !__flbf() I think which for non-buffered will cause a nop-fflush but for fully buffered will do an actual flush.

I think we REALLY want to have the fflush be a callback offered by libxo, otherwise the layering violations are pretty difficult to deal with.  Consider if libxo is outputting to a non-stdio buffer, then what is the paradigm?  Is it not better to give libxo a "flush" callback and have that exposed via the xop interface?


> 
> xo_flush flushes the data that libxo is buffering in the handle,
> which is used to avoid making malformed XML and JSON content.
> Then fflush can push that data out if needed.
> 
> The XOF_FLUSH flushes data after every call from the xo handle to
> the underlaying opaque stream; putting a flush at that point would
> likely be overkill.
> 
>> I think we just need a "cork/uncork" sort of api that will make it a 
>> single line?
> 
> I can make a flag to push container and list names as they are opened,
> so a function can close, add an inter-record string (a NL for NLDJSON),
> and reopen the tags.  Since I have the keys, I could add those also.

That sounds awesome.