Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!s41g2000prb.googlegroups.com!not-for-mail From: horos22 Newsgroups: comp.lang.java.programmer Subject: Re: tools for programming applets Date: Sun, 22 May 2011 05:18:57 -0700 (PDT) Organization: http://groups.google.com Lines: 40 Message-ID: References: <028d2009-98b7-43a3-b02d-83eaa89db79e@glegroupsg2000goo.googlegroups.com> NNTP-Posting-Host: 67.169.95.196 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1306066738 12084 127.0.0.1 (22 May 2011 12:18:58 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 22 May 2011 12:18:58 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: s41g2000prb.googlegroups.com; posting-host=67.169.95.196; posting-account=_qjMegoAAAAmC6fHnKsftlw5c47TS2H5 User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1,gzip(gfe) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4409 > 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, I understand that this is a security risk - if used in production systems. But as a development tool, it's invaluable. 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 *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. Suppose you had 10 developers working on an applet. What are they supposed to do? Duplicate the parent environment 10 separate times? 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 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.. Ed