Putting an entire server on the client machine
would seem to lose almost the entire benefit
of doing it as a thin-client.

What do you mean?  Of course a Swing
based GUI can be both web-based (hint -
JApplet) and self updating (Java Web Start)
which would, AFAIU, retain most of the
benefits of the thin-client concept.

Of course, if you are force to deal with
that horribly broken 'OS component'
made by MS, it complicates things slightly.

--
Andrew Thompson
* http://www.PhySci.org/ Open-source software suite
* http://www.PhySci.org/codes/ Web & IT Help
* http://www.1point1C.org/ Science & Technology

Am Wed, 04 Feb 2004 09:43:42 -0800 schrieb Vijay Kumar:

I just started something like this for timereporting. The solution for us
is a webstart application which will synchronize project description and
entered time data if the server is available. But this is of course more
or less a fat client app. Installing a simple http server will give you
IHMO the same, only with additional headache of a splitted client app
(server + browser).

Bye, Carsten

Well, this is a contradiction. Without a web server anything beyond
simple file viewing will become difficult or impossible when just using
a browser. In fact, since the web server is responsible for delivering
the web-based application to the thin-client, there is nothing left that
can deliver the application.

No server, no form processing. You either throw in some local web
server, you give them a real application or a local applet, hack tons of
JavaScrip (this is a Java, not a JavaScript group :-)) or you just give
them a text editor :-). In any case, you will not have a thin client. Or
at least not a thin client without some additional fat pieces of
software on the same machine.

In a totally different way. Instead of first selecting the technology
(web-based thin-cilent), and then trying to work around the limitations,
I would start with some real requirements, and then select a matching
technology.

[Note: What you call requirements are not requirements, but technically
constraints. A requirement defines what should happen, a constraint
defines how it should happen (e.g. choice of technology). A constraint
reduces a developer's ability to find a solution for the problem at
hand, while at the same time it takes the responsibility out of the
hands of the developer. The one insiting on the constraint (the choice
of technology) is responsible now. There is nothing wrong with
constraints in a software project. You usually have a lot of them. But
when they reduce your alternatives to close to zero, you should get rid
of them, and do a fresh start.]

Sure you can. I would hesitate to call that a thin client, but hey it is
your software. If you do so, your problem will be deployment. Exactly
the problem people try to avoid when going for a web-based thin-client
solution. Since this is a Java group, you could think about using Java
web start for software distribution and updates.

"Web-based architecture" is a buzzword and meaningless here. Swing is a
GUI toolkit. If you have a decent Java version in your browser (usually
using a plug-in), you can of course have Java Applets who use Swing. If
 that qualifies as "web-based architecture" or not is up to you.

/Thomas