«

Lew,

Think about it this way: an applet is a client in the same sense of the word as a browser is a client.

Instead of serving up html, you serve up code. This code is run locally, with potential input from the server, and it passes back output directly to the server.

Like it or not, this is a client/server paradigm. I can do a wireshark trace and see exactly the input that comes from the server - the code being downloaded, and the data being downloaded/uploaded to the server from the applet.

Now, in your paradigm of development, it may be helpful to *think* of the applet as a server-side object, but that's just a fiction, enforced by both convention and the structure of the tools. In the end, it really is a client - one hosted on a server, but a client nonetheless.

Again, you've thrown around some ugly adjectives, but it's only 'heinous' if you use it in some underhand way. It's like developing under http vs https - it simplifies the architecture, makes it easier for you to develop. It's like scaffolding; helpful when its there for building, removable when you are done.

Anyways, I'm not going to re-hash all you said, but one comment struck me as particularly irksome.

"bulky, resource intensive, extra-life-support-systems-required effort thatprogramming has become".
There's only your irrational resistance to the facts."

Really? I've had people suggest to me that - on a non-existant budget, in aplace where I'll probably only get limited access - that I rebuild the world, including databases and associated data, web configuration, any proprietary software that may be extant, and so on, *just* to work on a small corner of the site?

Instead of a simple configuration change limited to a single IP and perhapspassword protected, which allows a custom applet to run in an environment which is neither mission critical (or important), is a one-way app that hasno facilities for changing data on the server?

I'm sorry, but this is neither a security risk NOR an unreasonable request.

What *is* unreasonable is to call me a 'cracker' in a public forum, based on zero information, and yes, I'll take umbrage at that. Frankly, Lew, the malice in your responses is quite off-putting, and you should work on that.

Ed

On 05/23/2011 03:32 PM, horos22 wrote:
> Lew,
>
> Think about it this way: an applet is a client in the same sense of the word as a browser is a client.

You posted using a Google Groups interface that breaks the conversational
thread. Please repost in a fashion that respects the headers and doesn't
fragment the conversation.

AIUI, the "classic" Google Groups interface does not have the problem. In any
case, you are unlikely to receive responses if you insist on using an
interface that breaks the conversation, identifiable by the weird
"@googlegroups.com" address to which you sent your post. This is not a Google
Group; this is Usenet.

Please do not post that way again.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg

On Mon, 23 May 2011 12:32:11 -0700, horos22 wrote:

>
> Think about it this way: an applet is a client in the same sense of the
> word as a browser is a client.
>
About the only way I can think of to meet your requirement is to start by
coding the applet so it can be run both as an applet and as a free-
standing client, i.e. it must implement the applet interface and have a
normal main() method which will invoke the applet methods when run
outside a browser. This lets you test most of the applet's operation
against a remote server *but* it will still need to be loaded from the
server to confirm that it works correctly when invoked as an applet by
the target browser(s).

> Instead of serving up html, you serve up code. This code is run locally,
> with potential input from the server, and it passes back output directly
> to the server.
>
You're missing a major point. The applet *must* be downloaded at least
once by the browser and again each time the browser's cache is cleared.
The browser is the only client of the web server. The applet is just
something the browser can download from the web server and use as an
enhancement to let it communicate with a second (non-web) server sitting
alongside the web server.

> Now, in your paradigm of development, it may be helpful to *think* of
> the applet as a server-side object
>
Not 'helpful', but essential since it must be downloaded from the host
computer by the web server that the user's browser is talking to.

>it really is a client - one hosted on a server, but a client nonetheless.
>
Yes, but its not a client of the web server, just a mandatory payload
that must be requested from a web server sitting alongside its target
application server. Them's the rules and you're stuck with 'em.

I really don't see what you're kicking about, though. Its pretty trivial
to take an archive file containing the target web and application servers
and install copies on your desktop box. Since you're not concerned with
response time during development, even a fairly feeble desktop box should
cope: I've run Tomcat alongside the web browser on an NT4 box with no
problems and currently am running Apache, PostgreSQL and a full set of
Java development tools on a 512MB, 866MHz P3 box under RedHat Linux
(Fedora 13). Both set-ups handled development and testing quite
adequately.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |