Re: Support for compression in XHR?

Jonas: > Wouldn't that mean that it's the application (i.e. web page) and not the > client (i.e. browser) that decides to attempt compression or not? I.e. the > browser wouldn't try unless the web page had told it to do so. Yes, if a flag is employed, the application code is in control. Again,

Re: Support for compression in XHR?

mike amundsen wrote: Jonas: In the text below I meant: client = browser (or other hosting environment) component = xmlHttpRequest (or XHR, etc.) object available as part of the client/environment application = code running within the client/environment (i.e. script that can get an instance of

Re: [xmlhttprequest2] timeout and JSON

Sunava Dutta wrote: " I absolutely agree that it would rock if we could use the MS implementation." Thanks Jonas. As always, appreciated. Answers to your question What happens if there is a timeout in that state? 1) .readystate is set to 0 .status is set to 0 .responseXML is set to n

Re: Support for compression in XHR?

Jonas: In the text below I meant: client = browser (or other hosting environment) component = xmlHttpRequest (or XHR, etc.) object available as part of the client/environment application = code running within the client/environment (i.e. script that can get an instance of the component, etc.) M

RE: [xmlhttprequest2] timeout and JSON

" I absolutely agree that it would rock if we could use > the MS implementation." Thanks Jonas. As always, appreciated. Answers to your question > > What happens if there is a timeout in that state? > > > > 1) .readystate is set to 0 > >.status is set to 0 > >.responseXML is set to null >

Re: Support for compression in XHR?

mike amundsen wrote: Jonas: Your proposal with the flag seems like it's reverting to the "having to know" case, since you'd want to set the flag if and only if the server supports compression to avoid extra overheads, while still taking advantage of compression when the server supports it.

Re: Support for compression in XHR?

Jonas: > Your proposal with the flag seems like it's reverting to the "having to > know" case, since you'd want to set the flag if and only if the server > supports compression to avoid extra overheads, while still taking advantage > of compression when the server supports it. Well, seems I've

Re: Support for compression in XHR?

mike amundsen wrote: If i understand you, you're saying the coding of the page (HTML/JS) should 'know' that the target server does/does-not support compression for uploads and handle it accordingly. I assume you mean, for example, as a coder, I know serverX only allows posting an XML document,

Re: Support for compression in XHR?

If i understand you, you're saying the coding of the page (HTML/JS) should 'know' that the target server does/does-not support compression for uploads and handle it accordingly. I assume you mean, for example, as a coder, I know serverX only allows posting an XML document, while serverY only allo

Re: Support for compression in XHR?

mike amundsen wrote: Jonas: Good points. Wouldn't a better solution then be that when the flag is set always compress? And leave it up to the application to ensure that it doesn't enable capabilities that the server doesn't support. After all, it's the applications responsibility to know many

Re: Support for compression in XHR?

Jonas: Good points. > Wouldn't a better solution then be that when the flag is set always > compress? And leave it up to the application to ensure that it doesn't > enable capabilities that the server doesn't support. After all, it's the > applications responsibility to know many other aspects o

Re: Support for compression in XHR?

mike amundsen wrote: I think a reasonable approach would be to offer an optional flag to *attempt* compression on the upload. When set to "false" (the default), no OPTION call would be made and the content would be sent w/o any compression. When set to "true" the component can make an OPTIONS ca

Re: Support for compression in XHR?

I think a reasonable approach would be to offer an optional flag to *attempt* compression on the upload. When set to "false" (the default), no OPTION call would be made and the content would be sent w/o any compression. When set to "true" the component can make an OPTIONS call, inspect the result

Re: Support for compression in XHR?

I think a reasonable approach would be to offer an optional flag to *attempt* compression on the upload. When set to "false" (the default), no OPTION call would be made and the content would be sent w/o any compression. When set to "true" the component can make an OPTIONS call, inspect the result

Re: Support for compression in XHR?

Stewart Brodie wrote: Jonas Sicking <[EMAIL PROTECTED]> wrote: Stewart Brodie wrote: I disagree with any proposal that allows the application layer to forcibly interfere with the transports layer's internal workings. Use of encodings, persistent connections, on-the-fly compression are enti

Re: Support for compression in XHR?

Jonas Sicking <[EMAIL PROTECTED]> wrote: > Stewart Brodie wrote: > > I disagree with any proposal that allows the application layer to > > forcibly interfere with the transports layer's internal workings. Use > > of encodings, persistent connections, on-the-fly compression are > > entirely inte

Re: [widgets] i18n element VS unicode RLM/LRM

Marcos Caceres wrote: Hi, i18n-WG. In recent feedback we received from Addison Phillips regarding the Widgets 1.0: Packaging specification, he suggested that WebApps should add a -like element to our Widget Configuration Document format (so to allow bidi text to be declared). At our last F2F, W

XProc 1.0 nearing the end of (2nd) Last Call, comments invited

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You are listed in its charter as particularly relevant to the work of the XML Processing Model WG. We have had only a small number of relatively minor comments on our 2nd Last Call draft [1], and see this as evidence that we have converged on a stabl

[widgets] Minutes from 11 September 2008 Voice Conference

The minutes from the September 11 Widgets f2f meeting are available at the following and copied below: WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before September 18 (next Widet

Re: [xmlhttprequest2] timeout and JSON

Jonas Sicking wrote: Sunava Dutta wrote: XDR timeout doesn’t work with sync requests as there is no sync support in the object. I'd be thrilled if IE9's timeout property be adopted for XHR. (OK, thrilled would be an understatement!) http://msdn.microsoft.com/en-us/library/cc304105(VS.85).aspx