Re: tools for programming applets
horos22 wrote:
Attribution restored (shame on you, horos22!)
Joshua Cranmer wrote:
Java applets were designed to be as secure as possible. Hence why, for
example, they are forbidden from opening a network connection to
anywhere other than their source domain. Allowing you to replace your
own applet to run in another's context domain is a recipe for security
holes; in principle, you could allow the server to list other applets
that can run in their domain (in similarity to how CORS stuff works),
but that is essentially the same level of changes needed as hosting
another copy of the applet.
--
Josuha,
That's not how his name is spelled.
I understand that this is a security risk - if used in production
systems. But as a development tool, it's invaluable.
As a development tool, a copy of the server environment is what's invaluable.
What you ask is unnecessary and harmful.
Something smells bad about your setup, horos22. You can't fake a development
environment with heinous security hacks. What's actually going on? Come on,
you can tell us. We won't snitch.
Consider protocol development. When I develop a ssh client, or mysql
client, or iscsi client, I don't need to make a new server instance or
somehow have to duplicate the server environment. The tests are
Yes, you do. You are so wrong here. Of course you work in a duplicate
environment. Development directly in the production environment is stupid,
risky, unprofessional, idiotic, untoward, and really not recommended.
*client* driven. I change the client, and as long as the protocol
works, I can make whatever changes I want behind the scenes without
touching *anything* except the source code on the client.
But you aren't asking to change a *client* [sic]. You're asking to change a
server. But you don't want to do it safely, properly or ethically. Doesn't
smell right, in the sense that Stilton cheese left outin late August in El
Paso doesn't smell right.
Suppose you had 10 developers working on an applet. What are they
supposed to do? Duplicate the parent environment 10 separate times?
YES!
Duhhh.
Why not? Why do you seem so frelling horrified by that perfectly sensible and
common and proper approach?
Hm?
What if the central environment changes? Do you then need to propogate
those changes to all 10 daughter environments? what if two people want
to merge changes or then test their changes our versus production
data? Do they need then to impact production by having their applet
hosted in the production world?
This makes no sense. I can't believe there isn't something out there
What you suggest makes no sense, and is harmful.
to do this. Unix has a permissions system and its invaluable - you
and was not developed on the production box.
open up the permissions on things to do development, get stuff done,
and then close down the permissions when you ship. There's gotta be a
way to overcome the extreme development penalty inherent in cloning
That's rich, "extreme development penalty" for the safest, most common and
proper way to go. Hahaha. ROTFLMAO.
environments here; elsewise I feel damn sorry for the java [sic] applet
developer..
Get over it. I certainly don't feel sorry for you.
Do start attributing citations, please. Have you not posted to Usenet before,
horos22?
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg