[jsword-devel] Recent Updates

[Keith Ralston]

to a full swing GUI (100% client side) going through Applets, JNLP, Swing
GUI with remote processing, etc.
So speed is not always the priority.

I have written a stock trading application that runs completely in Java.
The system UI is in applets.  The system delivers live stock quotes and
performs real time trading.  The GUI only knows how to display and request
information.  All the processing takes place on servers.  A single 1GHz
server with 256Mb RAM can handle 1,000 concurrent users.  The system is
designed to allow n servers to be added to allow for as many users as the
company has bandwidth and hardware to serve.

We can structure JSword similarly, letting the actual search code run on a
server and then shipping results to the GUI.  Java does this very well.
This would give us a lightweight, portable client that has good performance.

-----Original Message-----
From: owner-jsword-devel@crosswire.org
[mailto:owner-jsword-devel@crosswire.org]On Behalf Of Joe Walker
Sent: Tuesday, August 13, 2002 1:17 PM
To: jsword-devel@bibletechnologieswg.org
Subject: RE: [jsword-devel] Recent Updates



Hi,

Keith wrote:
> Yep, I found where I got hung up in the Resource file.  I like
> your forward
> thinking about the URLs.  I was wondering if the engine would ever be
> separated from the Bible source files?  Do we not want the source
> files and
> the engine to be accessing a common file system for the sake of speed?

Yes if speed is the priority.

One of my ideas has been to have a clever installation where you start by
looking at a web-site using servlet type stuff (100% server side) and move
to a full swing GUI (100% client side) going through Applets, JNLP, Swing
GUI with remote processing, etc.
So speed is not always the priority.

URLs should be just as fast as Files for most things, and where they are not
(I think the SerBible does this to get hold of a RandomAccessFile) you can
always convert a URL("file:...") into a File.

> In any event, the code that looks for versions does construct
> File objects.
> I have modified this to remove an odd place where Windows causes two "/"
> characters to appear in a path.  This is in the common utility
> NetUtil.lengthenURL().  Win2k constructs the file: type URL with a
> File.separator at the end.  The function also postpends a
> File.separator.  I
> just added a switch to skip the postpend if a File.separator is the last
> character of the URL.toString().

That sounds sensible.

> In findBibles(URL), a few places we instantiate File objects to
> look for the
> versions directory.  These checked for trailing "/" characters.  I changed
> them to look for File.separator.

Does this need re-evaluating in light of my other mail on URLs?

Come to that can anyone verify that I am right? I've just looked at the w3c
spec and it does not mention file: at all!

Joe.