Re: chunked output

----- Original Message ----- 
From: "Charlie Poole" <[email protected]>
To: "FIT Developers" <[email protected]>
Sent: Tuesday, August 19, 2003 3:39 PM
Subject: RE: [Fit-dev] chunked output


> John,
>
> > > > > By using chunked encoding I can make FitNesse do this.  But it
means
> > > > > that
> > > > > FIT will need to spit out the results as soon as it makes them.
FIT
> > > > > needs
> > > > > chunked output.
> > > >
> > > > In a previous fit-like testing framework I found it advantageous to
> > > > process tables in other than sequential order. This was due to a
quirk
> > > > in the way the domain specialist chose to organize tables in her
> > > > spreadsheet. If we find a good way to allow subclasses of the
> > top level
> > > > Fixture then we could see this again in Fit. A top level fixture
could
> > > > override doTables and do them any way it wanted.
> > > >
> > > > I'm guessing by chunking Micah means that we write annotated html
for
> > > > each table as it is completed. This would be only one kind of
progress
> > > > indication that would be possible. Another would be some sort of
event
> > > > or callback as each cell is processed or each annotation is made. In
> > > > java I would do this with some sort of Listener interface. What
would
> > > > other implementations do?
> > >
> > > In C# you could use an interface or have the fixture provide an event
> > > to be subscribed to. You could do the analog of either in many other
> > > other languages, but maybe not all.
> > >
> > > This seems to introduce a third interface to those used by test
writers
> > > and fixture developers: the host application interface. To what extent
> > > do we believe this must be standard across all languages? Could we
> > > simply provice certain functionality and require the host to write the
> > > glue for the various implementations? Or does it have to look exactly
> > > the same to the host out of the box?
> >
> > I think it has to look the same, especially since we're talking
> > about FitNesse, which is spawning tasks in the various languages.
> >
> > Unless we wanted to put language specific support into FitNesse.
>
> What you say makes sense to me... Why not just use stdout for the output
> and let FitNesse or any other host choose whether to direct it to a file
> or pipe it into their program?

That's basically what FitFilter does now. The issue is that it waits until
it's
got the entire document processed before sending a result, and that is even
worse since suites are processed as one document.

The only real difference between FitFilter and FileRunner is that FitFilter
assumes that input is stdin and output is stdout, while FileRunner assumes
that input and output are files named on the command line.

John Roth


> Charlie Poole
> [email protected]
> www.pooleconsulting.com
> www.charliepoole.org
>
>
>
>
> _______________________________________________
> Fit-dev mailing list
> [email protected]
> http://lists.freepan.org/mailman/listinfo.cgi/fit-dev