From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Green <green@cygnus.com>
To: arenn@urbanophile.com
Cc: mauve-discuss@sourceware.cygnus.com, abies@pg.gda.pl
Subject: File access (was: Character Test)
Date: Fri, 08 Jan 1999 07:41:00 -0000
Message-id: <199901081540.HAA23902@rtl.cygnus.com>
In-reply-to: < 36957A24.B7BB761F@urbanophile.com > (arenn@urbanophile.com)
References: <36957A24.B7BB761F@urbanophile.com>
X-SW-Source: 1999-01/msg00002.html

Aaron wrote:
> I convertered Artur's Character test to the Mauve framework (a simple task)
> and checked into the gnu/testlet/java/lang/Character directory as
> unicode.java.

Cool! Will try this today.

> I'm using the Unicode 2.1.2 database file, which I also checked into
> the archive.

I was thinking about File usage the other day.  I'd like to suggest
that we introduce an abstract interface to test input data (like
UnicodeData.txt).  So rather than having testlets open files
themselves, they would pass the file name to the TestHarness, and the
harness would return a Reader.

PersonalJava has optional File support.  JavaCard has no File suport.
For systems with no File support you would build the test input data
into the final image.  Their special TestHarness would look up the
filename in some kind of dictionary and return a Reader on the in-core
image.

This would require:

- Tagging testlets with file info.  Something simple like:
	// Input: UnicodeData.txt

- A script for collecting Input info, and creating Java classes with
	the file contents as static data.

- Other bits of glue for treating these classes as Uses ones, etc.

Using this scheme could be a simple configure time option.

The only constraint for testlet authors would be that they are forced
the special harness method to access test input data.

Does this sound reasonable?

AG

-- 
Anthony Green                                               Cygnus Solutions
                                                       Sunnyvale, California