On 7 Apr 2007, at 15:37, Fergal Daly wrote:
I'd rather just give each thread its own stream and TAP::Parser and
mix everything together further upstream in that case. If you want to
capture all the TAP have each parser spool to a different file and
then concatenate them all.
How? For this to work, either each producer starts its own parser (so
now the test is running the harness) OR a producer has a way to signal
to the harness that a new stream is starting and it needs to attach a
new parser to it OR each producer writes to its own file and the
harness comes around and finds all the output files and parses them OR
something else that I haven't thought of.
The consumer listens on a port and the producer connects when it has
output?
Or we just prefix each line and merge the streams
[test1] plan 14
[test1] ok 1 Spork::Flum loaded OK
[test2] plan 3
[test1] not ok 2 Meta::Purgle is glibbed
[test2] ok 1 Subsystems init OK
and handle that as a separate protocol layer that muxes at one end
and demuxes at the other end. There's probably something that already
does that and if there isn't it'd be useful outside of TAP and
therefore worth releasing independently.
I don't think a mechanism for sending multiple streams over a single
pipe should be TAP specific or part of TAP. Making it part of the
test numbering scheme couples it far too closely to TAP - there's
just no need to pollute TAP in that way.
I think you just don't join TAP streams in that way. How do you
handle YAMLish diag blocks that follow a numbered test? How do you
handle plan lines?
You'd have to prepend a source identifier to each line - and doing
that is really just a standard trick (see logfiles) that doesn't
really feel like it should be part of TAP.
Yes, this is exactly what I said except the source identifier is just
a test number.
Why isn't the source identifier just a source identifier? It hasn't
got anything at all to do with test numbering.
Each source has a dedicated block and everything it
outputs is associated with that block. You don't need a weird textual
source identifier (although each block is a test and tests have names
so it does have a textual identifier, just not on every line).
I must watch out for those weird textual identifiers. Or 'names' as
they're otherwise known. They can really screw you up you know :)
Currently we have a situation where we cannot even assign diagnostics
to the relevant test
ok 1
# wibble
ok 2
# foobar
does "wibble" belong to the first or second test?
Yes, yes. That's what the YAMLish proposal (which your numbering
proposal pretty much breaks) addresses. I think the consensus is that
we're heading in the right direction with that.
> Using BEGIN/END works for the non-real time however it seems
like it
> would be better to use a solution that works equally well in either
> situation,
Trying to solve the realtime problem by turning each line of TAP into
a packet with a source idntifier and then streaming them over a
single pipe is bonkers. We don't need to mux/demux streams for
network transmission. TCP/IP does that pretty well.
I'm not particularly trying to solve it, I'm just pointing out that
you get it for free once you allow nested blocks and make each line
declare it's test number which are useful for other things anyway.
No you don't. You have to add a test number prefix to every line -
including non test lines. So instead of being part of the test
numbering it becomes a weird numeric source identifier.
From your "numbered paragraphs" comment I guess you think that nested
blocks are quite a natural feature.
I'm not sure what you mean by your TCP/IP comment. Are you saying we
should not reimplement the wheel and somehow leverage TCP/IP's muxing
abilities to solve a problem?
I'm saying that the normal way to have multiple independent streams
flowing across a network is to use TCP/IP.
If you find that you actually do need to multiplex multiple logical
streams onto a single TCP/IP connection you should probably implement
that as a content-agnostic protocol layer below your application
rather than trying to redesign your application's protocol so that it
doesn't mind multiple streams being jumbled up.
And when I say "should probably" I mean "would have to be certifiably
insane to consider doing other than" :)
--
Andy Armstrong, hexten.net
