CLI and HTTP diagnostics design

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I'm putting together a small PHP application which produces as its
output an XML file. The application needs to run from either an HTTP
request or a CLI invocation. HTTP requests don't come from a web
browser, they're called from an application that talks HTTP.

The issue I have one of diagnostics. The specification says there needs
to be a method for the user to see both runtime narration (i.e. what the
process does and why it chooses to do it), runtime warnings (i.e. non
fatal errors) and fatal errors.

The PEAR Log library seems to provide a lot of this functionality, with
various levels of message, etc. I thought I'd start with that.

A normal or fatal run is straightforward - one document goes back with
either the required information or a fatal error description.

The tricky bit is what happens when the user asks for the narration, or
there are warnings to return. Given the CLI invocation, I'd normally
just send the output - either as required or a fatal message - to
stdout, then narrations and warnings to stderr. But if the request comes
via HTTP I don't have stderr. I still need to give back the two types of
information, but I only have one data stream to give it back with.

I need to come up with a solution that a) does something sensible with
the one stream offered by an HTTP connection, and b) works in either
HTTP or CLI mode without context checking evaluations at all of its
Logging calls.

Does anyone have any advice?

Aches and pains at your desk? Try a little exercise: /

Re: CLI and HTTP diagnostics design

Quoted text here. Click to load it

Is this homework?  You wouldn't generally see this kind of "specification"
in the wild, because it doesn't make sense.  An HTTP request only has one
output stream.  If the output has to be XML, then that's going to occupy
the output stream.

If this is for debugging and tracing, one perfectly valid option is to add
the diagnostics and log messages as <!-- comments --> in the XML file. That
would work in either CGI or HTTP.
Tim Roberts,
Providenza & Boekelheide, Inc.

Re: CLI and HTTP diagnostics design

Quoted text here. Click to load it

An alternative approach would be to use firephp (http:// to write to the firebug console (a Firefox add-on).
Like the stderr/stdout method, that has the advantage in that the
content is seperated from the diagnostic stuff - and because the
diagnostic output is only included if the server detects an active
firebug console, it will not have any impact on applications using the
XML (not that including comments should have any impact).


Re: CLI and HTTP diagnostics design

Tim Roberts wrote:
Quoted text here. Click to load it

No, it's not homework. Why on earth would you think that?

'Specification' was the wrong word - I should have said 'design' in the
bit you quoted above. The question relates to standard implementation
patterns for designs that require multiple data streams to be
multiplexed down the single output channel PHP has available. I can't
believe I'm the first one to have come across the issue.

Quoted text here. Click to load it

Yes, that's one option. Better yet, use elements so they can be properly
manipulated - there's a lot of XSL in my pipeline. The issue there is
that everything further down the pipe needs to be aware that diagnostics
data might be mixed in with the meat - I wouldn't want that stuff
getting as far as the customer.

I've checked with the client and he's happy for me to use stderr for CLI
and the web server log for HTTP. That'll be good enough for now.

Thanks for the input.

Aches and pains at your desk? Try a little exercise: /

Site Timeline