You assume that I need someone to put constraints on a development tool that will protect me. I do not need the protection and promise not to complain if I somehow release code that doesn't work in the web browser versus what I need to test in debug mode.
It is also reasonable to make the default option to not allow the behavior but give the developer the ability to configure this as an option for testing purposes. . We are talking about a development tool that is hard wired to debugging "Java" code that will get converted to Javascript where the innovation step is to allow the developer to be more productive prior to deploying to javascript and running in a web browser. Sun provides the applet viewer for exactly this reason to allow the developer to write and debug applet code before adding the complexity and overhead of security models that are designed to protect the end user not the developer. Please understand the difference between hosted mode as a debug/ productivity tool used by developers and a web browser used by end users. I know you do I am just trying to make the point that all developers understand the difference. You actually create a situation where I will end up deploying applications that have more bugs because of the complexity of our production environment and size of data sets that makes it difficult to reproduce on a development machine. This means code does not get tested as well prior to moving into production which results in a higher number of defects and longer development cycles. It sounds like you have already decided that even though you have numerous requests in this thread to relax the restriction it is not going to happen. Should this discussion be moved over to the developer group or has it already been discussed? Is the tighter security restriction part of a google developed application tool or something used from an external open source tool? Just curious what triggered the change in a minor release of 1.5.2 to 1.5.3 and how hard it would be to relax the restriction as a config option. Thanks Scooter On Jan 9, 6:17 pm, Sumit Chandel <sumitchan...@google.com> wrote: > Hello sjn456, > > You're completely right. That's precisely why the previous behaviour was > corrected. It's browser security policies that restrict making calls to > other domains or ports. If we allowed these in hosted mode, we would be > setting developers up for a break once they go to production. What's more, I > believe the new corrected behaviour is the result of an update to the latest > XHR spec on supported browsers, meaning that allowing calls to go through to > other ports would mean drawing back to older XHRs. > > Cheers, > -Sumit Chandel > > On Wed, Jan 7, 2009 at 8:20 AM, sjn...@gmail.com > <nichols_sc...@yahoo.com>wrote: > > > > > The light bulb finally lit for me. There's browser security rules in > > place that only allow Ajax to communicate with the same server as the > > main page. If GWT hosted mode allowed it then in the future when you > > deployed to production your app wouldn't work. I'm going to change my > > implementation to have the external data sources route through the > > server, but may need to add load balancing because of the extra load > > now on the server. Nothings ever to easy. > > > On Jan 6, 1:10 pm, Scooter <willi...@gmail.com> wrote: > > > Please allow this to either be a configurable option or a prompt when > > > accessing external URL. I test against a variety of complex data > > > sources for our web server where duplicating on my development machine > > > is almost impossible. It is also an issue when we get a bug report in > > > production that I can point to the appropriate web server and debug > > > the problem. I can't upgrade to the latest 1.5 and really want to > > > avoid the proxy overhead. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
