Re: tools for programming applets
On 5/22/2011 8:18 AM, horos22 wrote:
Josuha,
While I am used to the spelling and/or pronunciation of my last name
being butchered, this is the first time in quite a while that I've seen
my first name incorrectly spelled ;-)
I understand that this is a security risk - if used in production
systems. But as a development tool, it's invaluable.
From a security risk, how would you lock it down in the production
system yet keep it available in development? By the time you start
trying to come up with mechanisms to allow that, you're not saving
yourself any effort compared to just making a new server or hosting
another install in a similar environment.
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.
Applets aren't exactly like an SSH client. While I'm not exactly sure
what your use-case it is, it seems to me that the applet is acting more
like a smart client that does middleware business management-y stuff; a
close analogue to this would be an intranet application.
Suppose you had 10 developers working on an applet. What are they
supposed to do? Duplicate the parent environment 10 separate times?
When I worked on an intranet project, that is precisely what we did.
Everything from the copy of code we ran to the LDAP and MySQL databases
we authenticated against were created as separate copies for every
developer.
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?
Yes to your first question; no to your second. It is possible to
directly copy the production values to the non-production stuff.
This makes no sense. I can't believe there isn't something out there
to do this. Unix has a permissions system and its invaluable - you
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
environments here; elsewise I feel damn sorry for the java applet
developer..
From my perspective, when hosting a webservice (including applets), one
key thing you need to be sure of is that you do not treat the
development testbed as the production environment. What happens if you
accidentally introduce a security leak for debugging purposes? The
entire world would see it in the production, while the development
version remains (theoretically) locked down within a corporate firewall.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth