Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #4488 > unrolled thread

Re: tools for programming applets

Back to article view | Back to comp.lang.java.programmer

Contents

  Re: tools for programming applets horos22 <ed.peschko@gmail.com> - 2011-05-23 12:32 -0700
    Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-23 17:06 -0400
    Re: tools for programming applets Martin Gregorie <martin@address-in-sig.invalid> - 2011-05-23 23:01 +0000

#4488 — Re: tools for programming applets

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 that programming 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 a place 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 perhaps password protected, which allows a custom applet to run in an environment which is neither mission critical (or important), is a one-way app that has no 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

[toc] | [next] | [standalone]

#4496

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/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#4500

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       |

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web