- From: Peter Sorotokin <psorotok@adobe.com>
- Date: Mon, 22 Nov 2004 22:28:12 -0800
- To: Jan-Klaas Kollhof <jan@kollhof.net>, www-svg@w3.org
At 01:05 AM 11/23/2004 +0100, Jan-Klaas Kollhof wrote: >Hello, > >There was no reply to my previous mail. >http://lists.w3.org/Archives/Public/www-svg/2004Nov/0065.html > >The networking sections do need more content and details. > >in addition to the mail above: >if an event is fired for the URLRequest it sould have a refference to the >request object so one does not to save it somewhere in the code >to work with it when the event is fired. Events always have a target attribute (comes from events::Event) and it will point to URLRequest. >I'd like the responseText be part of the event object also the response >headers. >They are responses, and that's what the event represents teh server's >response. >responseText is not part of a request it is the result of it. We'd like to keep compatibility with Mozilla/IE XMLHTTP where possible. >I really want events for partial data arrival for URLRequest. >This would be very useful for showing progress. And it would not be >difficult to impl. Yes, but we can extend it later. The points that you make here (and below) are good, but we want to keep it simple for now. >There should be some way to send binary data created by the script over >the sockets and the URLRequest. >This is a problem because EcmaScript only has strings or arrays to work with. >A bytestream object would not be bad having something like feedByte(byte), >feedInt16(int16), feedInt32(int32),... >I guess I am getting out of the scope for SVG here. > >But there must be some way to tell how strings are to be sent (encoding) >and how data is to be decoded when coming back. Again, one step at a time. We would like to get easy-to-do stuff first. >And please keep the same domain policy if you want but no restrictions on >the ports. >To have sockets is not useful if I can't use them but to make calls to an >HTTP server. >Unless of course I write a hybrid HTTP-Whatever-HowKnowsWhatSocket server. >(Someday we will have only HTTP on prot, and all communication will be >handled over HTTP on port 80. >Then the day will come that we disable HTTP on port 80 because it is not >safe ... ) > >If we allow the user to open a file for upload or processing in the >script, why not let the >user do the same for saving data to files generated within the script >using the same technique as opening a file? >It would be just as save as opening a file. > >What about safe clipboard access. >As discussed before by others as well: >The user initiates a paste action as recognized by the UISystem the user >is working in. >E.g pressing Ctrl-V or selecting paste from a context menu. >An event is fired and a Listener can now access the pasted data as part of >the event object. >The same for cut and copy. The Listner can set data as part of the event >object. >This is safe and will not allow any script to mess with the clipboard >without the user specifically asking for it >by initiating a cut/copy/paste action. It is probably too late for these. Peter >It would be pretty much a bad hack to missuse a text element and DOM text >events for that. > >It's too late to come up with anything else. >Looking forward to SVG1.2 > > >Jan > >-- >_________________________________________________ > >Jan-Klaas Kollhof >Founding Partner, Vectoreal >http://www.vectoreal.com >phone: +49 174 968 9477 >email: jan@kollhof.net >web: http://jan.kollhof.net >_________________________________________________ > >
Received on Tuesday, 23 November 2004 06:28:23 UTC