- From: <ronan@roasp.com>
- Date: Thu, 4 Nov 2004 09:42:25 -0500 (EST)
- To: "Thomas DeWeese" <Thomas.DeWeese@Kodak.com>
- Cc: "Boris Zbarsky" <bzbarsky@mit.edu>, "Denis Bohm" <denis@fireflydesign.com>, www-svg@w3.org
> > Boris Zbarsky wrote: > >> As a web browser developer, I can tell you that the only way we'd >> possibly >> implement a feature like this is by allowing it to only connect back to >> the originating server, most likely with a restriction on which ports it >> can connect to. > > Why would you restrict ports if you restrict to the originating > server? If they want to hack themselves let them. BTW you > absolutely should not allow even HTTP requests to anything but > the originating server from Script, otherwise they can browse > a persons intranet, (links are different because the originating file > doesn't get access to the new content). > I agree with Thomas. >> Attempts to do anything else would result in an >> exception being thrown, without the user being consulted. That's what we >> do now for many far more restrictive cases (XSLT comes to mind here, as >> do XMLHttpRequest, etc). > > Sure, this would be totally reasonable. > >> The problem is that given the likely restrictions UAs will have to place >> on the usage of this interface it may well be no more useful than >> existing interfaces... and possibly less useful. > > Sorry, I totally disagree, this is still a very useful interface. > Not everything on the web is or should be HTTP. There are many > cases where you want long lived connections with Bi-directional > data. > > I agree with Thomas. There are many perfectly good use cases for getting out of HTTP. For example, bidirectional comms. Clearly, the UA and the application implementers need to consider the consequences of accessing multiple ports. But that is an UA/application implementation problem and not a communciation standard problem, imho. I desperately need and desire bidirectional non-polled communications, and most of the systems I write are much uglier and harder to write because of their lack of socket support. Unless SVG supplies this, I will have no choice to work with SVG within batik or another customisable browser like Jan-Klaas is doing. I would very much prefer to have the UA provide this as standard than have to fight with the customer's desktop team to get this functionality on the client machines. Ronan >
Received on Thursday, 4 November 2004 14:42:32 UTC