Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: tools for programming applets Date: Sun, 22 May 2011 08:37:58 -0400 Organization: albasani.net Lines: 91 Message-ID: References: <028d2009-98b7-43a3-b02d-83eaa89db79e@glegroupsg2000goo.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.albasani.net Z5tBxKtdL7PoYy8Btq5gKS6YPj3l3hs/3uKUSYnEFf8FlJqn6cGZJUCG+ZhLzrXnKDQyIddQoueSI4g84sQXmX1mUyDt2zVt/aZI+XjnCjACgiExZflrBgsnxNDfUN+y NNTP-Posting-Date: Sun, 22 May 2011 12:37:53 +0000 (UTC) Injection-Info: news.albasani.net; logging-data="vYHNfFWDz0wDt8//m2W5nzKTB5alG/FiLEvJcI/7I1IOIE9aTWm10ybuQ+nKqlUB+ET32u9f3+3NylWWtXU3sJygmdhd24Pzy2nw/6QieNT+8Hsp0j9neLs+2lkXfQM8"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:e/kkyPnWQJDHOTp4giIkUbhX7YQ= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4412 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