--- Adam Kennedy <[EMAIL PROTECTED]> wrote: > > While I agree that this caused problems, those modules were relying > on a > > format that was not spec'ed out or documented. > > That is irrelevant. You put something into CPAN, get massive numbers > of > people using it, and leave it alone and have it remain stable for 4 > years, it becomes an API whether you wanted it to be or not :)
I'm sure most folks here are familiar with the aforementioned buffering issues, but on the off chance you don't know the sorts of difficulties that writing to separate output streams causes, read Dominus' "Suffering from Buffering" (http://perl.plover.com/FAQs/Buffering.html) What's frustrating about this is that I completely agree with Adam. We cannot simply have error and diagnostic output shunted to STDOUT. What about having the error and diagnostic information sent to both STDERR *and* STDOUT? That could solve the buffering problem, but we'd likely have duplicate information being output. Is there an easy solution? If we can solve this problem, then I can more reliably write a grammar that can be applied to a single stream of data. I've toyed with the idea of TAP::Parser, but we're not there yet. That raises the next issue. What if someone wants more diagnostic information or more complete failure information? We might find things useful enough that that we feel compelled to update TAP. If so, TAP needs to be versioned and we need to figure out how to accomodate that. Also, how do we want to handle got/expected failure information in Java or C? There are pretty rich data structures we could put out there and YAML might help. That would also likely simplify a parser. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
