- From: mike amundsen <mamund@yahoo.com>
- Date: Thu, 11 Sep 2008 23:15:13 -0400
- To: public-webapps@w3.org
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.) Mike A On Thu, Sep 11, 2008 at 11:01 PM, Jonas Sicking <jonas@sicking.cc> wrote: > mike amundsen wrote: >> >> Jonas: >> >> <snip> >>> >>> 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. >> >> </snip> >> >> Well, seems I've muddled things a bit by mixing concerns of >> cross-domain, compression support, and security in an overly simple >> suggestion. >> >> My intention was to allow clients to decide if they want to *attempt* >> compression, not *force* it. Thus, it could be exposed as an flag in >> the component in an effort to cut down on extra traffic between client >> and server. If the flag is set to "false", don't try query the server >> to see if it supports compression. This is on the assumption that a >> client must execute an OPTIONS call in order to discover if the server >> supports compression on uploads. This model would make the whole >> conversation transparent to the application developer, but not the >> component developer. > > What does "client", "component" and "application" mean in the above > paragraph? > > / Jonas > -- mca http://amundsen.com/blog/
Received on Friday, 12 September 2008 03:15:48 UTC