Re: Brain Dump of Towards FIT 1.0 OpenSpace session

----- Original Message ----- 
From: "Al Chou" <[email protected]>
To: "FIT Developers" <[email protected]>
Sent: Friday, August 22, 2003 2:16 AM
Subject: Re: [Fit-dev] Brain Dump of Towards FIT 1.0 OpenSpace session


> > > Thanks for the clarification, John.  OK, so let's substitute "FIT" for
> > > "FitNesse" in my original question.  Rather than (or in addition to,
for
> > those
> > > languages that have no Java compatibility) having FIT re-implemented
in
> > > numerous languages, why not have one core FIT that allows fixtures to
be
> > > written in whatever language you choose?
> >
> > It's an interesting thought. You'd need an interface program in the
> > target language, though. You'd also need to do a considerable amount
> > of reengineering of the FIT core, and you'd have to insure that the
> > new style fixtures weren't substantially more difficult to write than
the
> > older style fixtures.
>
> I guess the re-engineering might be in the form of having some core
facility
> that would parse the HTML tables and send the meaning of the data therein
to
> the fixture (so as not to be forced to implement type adapters in every
> language in which one wants to write fixtures, as you mention below).
There's
> some perhaps difficult decoupling of the functionality in the current
concept
> of a fixture that would need to be done.  Or maybe implementing type
adapters
> in a language is the price that language's users have to pay in order to
play
> with FIT.  It's less coding than re-implementing _all_ of FIT in the
target
> language, right?

Since the FIT core doesn't have access to the fixtures, there's no way
it can know what the actual data types are without a lot of communication
at the start of table interpretation. Also, it makes it very difficult to
handle
language and application specific type adapters.

I don't see enough benefit to justify the additional complexity. In fact,
at one point I thought of pushing type conversion to the fixtures
themselves; the fixtures, after all, know what's needed better than some
global framework. It's still an idea that has a bit of an appeal.

> Though it just occurred to me that if the interface/protocol used to
> communicate table data between the FIT core and the fixtures included a
set of
> standard data types (reminiscent of XDR; or better, a set of
self-describing
> data types, perhaps based on a core set of primitive types [such as n-byte
> integers, for integral types]), then type adapters could be implemented
just
> once for all, and the main thing that would have to be provided per
language is
> the protocol interpreter/translator.

Standard data types are something we have to put up with when we're
coupling systems built by different organizations to what are supposedly
common specs. They are not something we should have to limit ourselves
to in a test framework that is supposed to be customer friendly.

> > A much more lightweight text-based protocol would do fine. If you have
to
> > have XML, so be it, but I consider it major overkill when all you need
is to
> > transfer tables and counts back and forth.  A CSV variant would work
> > just fine.
> >
> > The more I think about it, the more I like it. There are a bunch of
> > possibilities here, I think.
> >
> > John Roth
>
> That's fine, I was just trying to point out possibilities that were new,
at
> least to me.  I agree that there's no need for a heavy protocol yet, if
ever.

Here's a first cut at a protocol. It's basically a comma separated values
(CSV)
with one cell per line.

Data sent to the language dependent stub have four fields:
1. table number - integer
2. row number - integer
3. column number - integer
4. content - character string with certain characters (comma, nl, lf, cr,
esc) escaped.

Data returned from the language dependent stub has more fields:

1. table number - integer
2. row number - integer
3. column number - integer
4. status - specific character values (see below)
5. returned value - character string (depends on status)

status values:

input-accepted (no return value)
input-error message (error message returned)
input-exception (stack trace returned)

output-accepted (no returned value)
output-incorrect (returned value)
output-error message (error message returned)
output-exception (stack trace returned)

ignored (no returned value)

However, there's a special case return for an inserted row:

1. I - literal character capital I
2. new row number - integer, counts from the last row in the original table
3. after row number - integer, row to insert this row after.

Inserted columns are implicit; if the column number exceeds the
highest number currently in the row, the row is extended.

Escaping is always an issue with CSV, that's why there are so
many different minor and incompatible variations out there!
The escape character is a backslash.

B - Backslash
C - Comma
n - new line
r - carriage return
l - line feed

Note that to produce a backslash, you code \B, ***NOT*** \\,
and to produce a comma, you produce \C, not \,.
The reason for this rather unusual spec is that it makes the
<string>.split(",") method work properly with the lines.
The reasoning for the backslash is a bit murkier, but has to
do with simplifying regex replacements.

Another issue: ASCII or UTF-8? I'm leaning toward
UTF-8, but I don't know how much trouble it would cause
for other languages. Java is obviously cool, so is
Python and I'd be very surprised if .NET couldn't handle
it with ease. Ruby? Perl?

Comments?

John Roth






>
> Al
>
> =====
> Albert Davidson Chou
>
>     Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> _______________________________________________
> Fit-dev mailing list
> [email protected]
> http://lists.freepan.org/mailman/listinfo.cgi/fit-dev