Re: chunked output

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


> >
> > Listener would do fine by me.  I don't know that it would do fine
> > by Fitnesse, though. The interface there is through
> > stdin/stdout/sdterr,
> > so I'd assume I'd need some kind of marshal,  unmarshal interface.
> >
> > Micah?
> >
> > John Roth
> >
>
> Listner would do fine by me as well... as long as each implementation had
a
> Listener derivative that spit out a table at a time.
>
> Perhaps this is a good point to share my thoughts on FitNesse integration.
> Right now there are two components, FitFilter for single executions and
> RecursiveAllFiles for running suites.  RecursiveAllFiles is clucky and I'd
> like to get rid of it.  There should be only ONE piece that glues FitNesse
> to FIT and that should be FitFilter.

Agree totally. In fact, I haven't tested the Python RecursiveAllFiles with
FitNesse yet. It works in isolation, though. Now, I won't bother.

> FitFilter could be a much better solution to running suites.  Currently
> FitFilter works like this:
> 1. html is recieved from stdin
> 2. read from stdin until EOF
> 3. process
> 4. write results to stdout
> 5. exit
>
> To run a suite FitFilter would have to be able to seperately run several
> documents all in the same jvm or process.  The new flow of operation would
> be somthing like this:
>
> 1. html is recieved from stdin
> 2. read from stdin until the end of document

I suspect this would need to be a test for the </html> tag. I don't
believe that stdin allows closing and reopening.

> 3. process and write results to stdout one table at a time (to enable
> chunking)

I think the hook here is fairly simple, but we'll have to look at the
code as to how to structure it.

> 5. wait for next client action
> 6. exit signal is recieved from stdin
> 7. exit

I'm not at all certain we want to process multiple documents in one
execution of FitFilter - it would be simpler if FitNesse simply
executed them one at a time, unless the Java VM startup is simply
too prohibitive. Python startup doesn't look that bad, and I can't
speak to the others.

> This implies some protocol through which FitNesse and FIT will comunicate.
> It can be rediculously simple but all implementations of FIT would have to
> abide by it.

As long as we send the output HTML out so that each chunk ends
with the </table> tag, it should work. FitNesse would have to take
care of closing it up properly, or merging it so that the user saw a
complete document rather than a truncated one.

> FitFilter could make use of some Listner that writes a table at a time.

I think that's the way it would have to be.

> I realize this is becoming complex but I believe it to be the simplest
> solution given the constraints.
>
> Micah
>
>
>
> _______________________________________________
> Fit-dev mailing list
> [email protected]
> http://lists.freepan.org/mailman/listinfo.cgi/fit-dev