Re: Brain Dump of Towards FIT 1.0 OpenSpace session

--- [email protected] wrote:
> 
> ----- Original Message ----- 
> From: "Al Chou" <[email protected]>
> To: "FIT Developers" <[email protected]>
> Sent: Thursday, August 21, 2003 7:48 PM
> Subject: Re: [Fit-dev] Brain Dump of Towards FIT 1.0 OpenSpace session
> 
> 
> > --- [email protected] wrote:
> > >
> > > ----- Original Message ----- 
> > > From: "Al Chou" <[email protected]>
> > > To: "FIT Developers"
> <[email protected]>
> > > Sent: Thursday, August 21, 2003 7:02 PM
> > > Subject: Re: [Fit-dev] Brain Dump of Towards FIT 1.0 OpenSpace session
> > >
> > >
> > > > --- [email protected] wrote:
> > > > >
> > > > > ----- Original Message ----- 
> > > > > From: "Al Chou" <[email protected]>
> > > > > To: "FIT Developers"
> > > <[email protected]>
> > > > > Sent: Thursday, August 21, 2003 5:18 PM
> > > > > Subject: RE: [Fit-dev] Brain Dump of Towards FIT 1.0 OpenSpace
> session
> > > > >
> > > > >
> > > > > > I couldn't find a saved message that made sense to reply to, so
> I'm
> > > adding
> > > > > it
> > > > > > to this thread.
> > > > > >
> > > > > > Lately I've been thinking more than usual about cross-language
> > > > > compatibility,
> > > > > > and I wonder whether anyone has mentioned trying to add BSF
> capability
> > > to
> > > > > FIT
> > > > > > or FitNesse so that any language that's been implemented in Java
> > > (Jython,
> > > > > > Tcl/Java [Jacl and/or Tcl Blend], JRuby, JScheme, and many many
> > > others) or
> > > > > can
> > > > > > do Java FFI could be used to write fixtures.  I was pleasantly
> > > surprised
> > > > > to
> > > > > > discover that a future version of Eclipse should have BSF
> included.
> > > > >
> > > > > Say what? I'm having a severe case of acronoym overload. What's
> > > > > a BSF, what's a FFI? I recognise Jython, so the rest of the
> languages
> > > > > in that clause are ok.
> > > > >
> > > > > In any case, Fitnesse doesn't care - writing fixtures in one
> language
> > > > > to drive an application in another language is a FIT issue.
> > > > >
> > > > > John Roth
> > > >
> > > > Sorry.
> > > >
> > > > BSF = Bean Scripting Framework, born at IBM, now at Apache
> > > > http://jakarta.apache.org/bsf/
> > > >
> > > > FFI = foreign function interface
> > > >
> > > > I may have misunderstood, but I thought I had read remarks about
> FitNesse
> > > > calling fixtures written in languages other than Java.
> > >
> > > Yes, it does, but what it does is call a driver in that language in its
> own
> > > process (using the Java equivalent of fork) so there is no language
> > > compatability issue. So, for example, there's a Java version of FIT,
> > > there's a .NET version of FIT, there's a Python version of FIT,
> > > and so forth. To invoke the Python versions, Fitnesse builds a
> > > command something like:
> > >
> > > Python FitFilter.py <path stuff> <working directory>
> > >
> > > and passes it the HTML on its stdin, getting the result HTML
> > > by reading the stdout and stderr.
> > >
> > > John Roth
> >
> >
> > 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?

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.


> The other difficulty I see is that you'd need a JVM, which isn't
> needed for any other purpose if you're not running FitNesse. And
> that makes is more difficult to modify FIT if your team doesn't
> do Java.

Yes, I agree.  For instance, changing from all-native Python FIT with Python
fixtures to a "kernel FIT" in whatever non-Python language certainly introduces
possibly undesired dependencies on that language.


> How would you handle type adapters? That whole mechanism
> is inherently language specific, which means they would have to
> be reimplemented on the target language side.

See remarks above.


> > The original FIT is in Java, which
> > happens to have a lot of other languages implemented in it, but as long as
> an
> > interface was exposed that many other languages could work with, it
> wouldn't
> > matter what language the core FIT was written in (a recent thread on
> Ruby-talk
> > brings to mind the possibility that rather than exposing an
> > implementation-language-specific [e.g., Java or C] API, the public
> interface
> > could be XML-RPC, SOAP, or some other already-language-neutral
> technology).
> 
> No way do I want something as heavyweight as those two! AFIC, anyone
> who's trying to do acceptance testing with FIT across a network connection
> from the program under test is, to put it mildly, working way too hard and
> needs a vacation - desperately.

I agree it'd be nutty to going across anything but a pretty fast network
connection, but you don't have to be using a network to use protocols such as
these.  In any case, I just put it out as an interesting thought that I came
across today.


> 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.



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