qooxdoo remote I/O and server backends

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

qooxdoo remote I/O and server backends

Helder Magalhães

Hi everyone! :-)

I've experienced a few remote I/O issues which were reported [1] and mostly
fixed. The one relative to bug 1017 [2] was marked invalid which made me dig
further - I was sure I wasn't dreaming when I saw it! :-D This is a
follow-up for that discussion...

The investigation result was that the tested back-end was (and still is)
using a feature known as "mixed-mode" [3]. This causes the query component
of the URL (everything after the interrogation mark) to be (internally) seen
as appended to the POST body received (separated by an ampersand as if it
was part of a composed "?param1=value1&param2=value2&etc." GET request.

This thread's aim is to:
 1. Query the community to realize if such feature is available/used in
other back-ends - even (and specially those) not based in the ones provided
by the qooxdoo project [4]. If so, how did different back-ends handle the
issue;
 2. I was able to find single vendor (Oracle) documentation [3] and I
believe it would be know if this is part well-known standard (such as HTTP
1.0 [5], HTTP 1.1 [6] or any other specification and/or recommendation);
 3. The current proposed change to support such behavior is through a
configuration setting (maybe a
boolean "UseMixedMode" property, whose default value was the current
behavior) which would allow disabling any URL modification [7]. The idea was
to know how does the community feel about this in order to attach a feature
request afterward. Also, (possibly better) proposals are more than welcome!
;-)

Best regards,

 Helder Magalhães


[1] http://www.nabble.com/Remote-I-O-fixes-and-version-0.7.4-td18198664.html
[2] http://bugzilla.qooxdoo.org/show_bug.cgi?id=1017
[3]
http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b12303/concept.htm#1005692
[4] http://qooxdoo.org/documentation/0.7/rpc
[5] http://www.ietf.org/rfc/rfc1945.txt
[6] http://www.w3.org/Protocols/rfc2616/rfc2616.html
[7] http://bugzilla.qooxdoo.org/show_bug.cgi?id=1017#c7
--
View this message in context: http://www.nabble.com/qooxdoo-remote-I-O-and-server-backends-tp18485656p18485656.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo remote I/O and server backends

Derrell Lipman
On Wed, Jul 16, 2008 at 8:09 AM, Helder Magalhães <[hidden email]> wrote:

 3. The current proposed change to support such behavior is through a
configuration setting (maybe a
boolean "UseMixedMode" property, whose default value was the current
behavior) which would allow disabling any URL modification [7]. The idea was
to know how does the community feel about this in order to attach a feature
request afterward. Also, (possibly better) proposals are more than welcome!
;-)

What you and the referenced link are describing are behaviors of web servers / backends.  Although we can allow sending or not sending parameters attached to the URL (via some property setting, boolean, etc.), the issue remains of how to avoid caching.  (The property "prohibitCaching" in qx.io.remote.Request is already there, and can be set to false to avoid the parameter being added to the request, although that also prevents sending the "Pragma:no-cache and Cache-Control:no-cache headers as well.)  The parameter we currently send ("nocache") is there solely to ensure that the URL is unique on each request so that the request is processed each time rather than pulling a previous response from a cache.  Hopefully we'll hear from those with real expertise in this area, but I strongly suspect that leaving off that parameter will lead to random problems dependent on the browser, settings of the browser, web server, and settings of the web server.  Testing an application would become extremely difficult.

Since the name of the parameter that is automatically added to the URL is known, an application running on a server that implements Mixed Mode could also simply ignore that parameter.  It's called "nocache".

Derrell


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo remote I/O and server backends

Helder Magalhães


Derrell Lipman wrote:
>
> What you and the referenced link are describing are behaviors of web
> servers / backends.
>
True, that's exactly what I'm trying to ask the community about: are there
other back end which are already dealing with this? If so, how was it worked
around up till now? Is this seen as a feature or an issue?


Derrell Lipman wrote:

>
> Although we can allow sending or not sending parameters
> attached to the URL (via some property setting, boolean, etc.), the issue
> remains of how to avoid caching.  (The property "prohibitCaching" in
> qx.io.remote.Request is already there, and can be set to false to avoid
> the
> parameter being added to the request, although that also prevents sending
> the "Pragma:no-cache and Cache-Control:no-cache headers as well.)  The
> parameter we currently send ("nocache") is there solely to ensure that the
> URL is unique on each request so that the request is processed each time
> rather than pulling a previous response from a cache.
>
HTTP 1.0 has "Pragma: nocache" and "Expires" (set to a past date) headers;
HTTP 1.1 has "Cache-Control: no-cache"; possibly there are other
headers/header combinations. I believe the caching problem is more put from
a server perspective...


Derrell Lipman wrote:
>
> Since the name of the parameter that is automatically added to the URL is
> known, an application running on a server that implements Mixed Mode could
> also simply ignore that parameter.  It's called "nocache".
>
Yes, I'm considering disabling the server behavior. The intention with this
thread was to create some debate on possible use cases and warn who might
have already bump in a similar situation. That's one of the reasons why I've
proposed that, if some changes were to be implemented, the default behavior
would always be the actual (appending "nocache" to the URL), which is the
best from a fail-safe perspective for this imperfect world. ;-)

Regards,

 Helder Magalhães
--
View this message in context: http://www.nabble.com/qooxdoo-remote-I-O-and-server-backends-tp18485656p18491660.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo remote I/O and server backends

Helder Magalhães


Helder Magalhães wrote:
>
> HTTP 1.0 has "Pragma: nocache" and "Expires" (set to a past date) headers;
> HTTP 1.1 has "Cache-Control: no-cache"; possibly there are other
> headers/header combinations. I believe the caching problem is more put
> from a server perspective...
>

Well, I was forgetting about an important detail: POST requests are, AFAIK,
never (?) cached as this is would be a serious violation of the
specification. Regarding HTTP 1.0 ([1], page 31):

   Applications must not cache responses to a POST request because the
   application has no way of knowing that the server would return an
   equivalent response on some future request.

And, regarding HTTP 1.1 [2]:

  Responses to this method are not cacheable, unless the response includes
appropriate
  Cache-Control or Expires header fields. However, the 303 (See Other)
response can be
  used to direct the user agent to retrieve a cacheable resource.

The caching problems pose mostly into GET requests. This is implemented in
the proposed patch [3], where not changing the URL (by using the "nocache")
is only made for POST requests. :-)

Said that, if anyone has knowledge of a proxy and/or Web server which caches
POST requests, please share!

Regards,

 Helder Magalhães

[1] http://www.w3.org/Protocols/rfc1945/rfc1945.txt
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
[3] http://bugzilla.qooxdoo.org/attachment.cgi?id=314
--
View this message in context: http://www.nabble.com/qooxdoo-remote-I-O-and-server-backends-tp18485656p18508585.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo remote I/O and server backends

Derrell Lipman
On Thu, Jul 17, 2008 at 9:41 AM, Helder Magalhães <[hidden email]> wrote:


Helder Magalhães wrote:
>
> HTTP 1.0 has "Pragma: nocache" and "Expires" (set to a past date) headers;
> HTTP 1.1 has "Cache-Control: no-cache"; possibly there are other
> headers/header combinations. I believe the caching problem is more put
> from a server perspective...
>

Well, I was forgetting about an important detail: POST requests are, AFAIK,
never (?) cached as this is would be a serious violation of the
specification. Regarding HTTP 1.0 ([1], page 31):

  Applications must not cache responses to a POST request because the
  application has no way of knowing that the server would return an
  equivalent response on some future request.

And, regarding HTTP 1.1 [2]:

 Responses to this method are not cacheable, unless the response includes
appropriate
 Cache-Control or Expires header fields. However, the 303 (See Other)
response can be
 used to direct the user agent to retrieve a cacheable resource.

The caching problems pose mostly into GET requests. This is implemented in
the proposed patch [3], where not changing the URL (by using the "nocache")
is only made for POST requests. :-)

That is a highly relevant detail. :-)

What do y'all think of this (untested) patch:


From 4d3678a2eb05e15e6fd81d0e38acc4d7a2a6aed9 Mon Sep 17 00:00:00 2001
From: Derrell Lipman <[hidden email]>
Date: Thu, 17 Jul 2008 10:39:36 -0400
Subject: [PATCH] Add option to avoid URL modification for cache prevention on POST request  Derrell


Signed-off-by: Derrell Lipman <[hidden email]>
---
 .../framework/source/class/qx/io/remote/Request.js |   35 ++++++++++++++-----
 1 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/qooxdoo/frontend/framework/source/class/qx/io/remote/Request.js b/qooxdoo/frontend/framework/source/class/qx/io/remote/Request.js
index dab0b18..b864e3e 100644
--- a/qooxdoo/frontend/framework/source/class/qx/io/remote/Request.js
+++ b/qooxdoo/frontend/framework/source/class/qx/io/remote/Request.js
@@ -263,13 +263,24 @@ qx.Class.define("qx.io.remote.Request",
     /**
      * Prohibit request from being cached.
      *
-     * Setting the value to <i>true</i> adds a parameter "nocache" to the request
-     * with a value of the current time. Setting the value to <i>false</i> removes
-     * the parameter.
+     * Setting the value to <i>true</i> adds a parameter "nocache" to the
+     * request with a value of the current time, as well as adding request
+     * headers Pragma:no-cache and Cache-Control:no-cache.
+     *
+     * Setting the value to <i>false</i> removes the parameter and request
+     * headers.
+     *
+     * As a special case, this property may be set to the string value
+     * "no-url-params-on-post" which will prevent the nocache parameter from
+     * being added to the URL if the POST method is used but will still add
+     * the Pragma and Cache-Control headers.
      */
     prohibitCaching :
     {
-      check : "Boolean",
+      check : function(v)
+      {
+        return typeof v == "boolean" || v === "no-url-params-on-post";
+      },
       init : true,
       apply : "_applyProhibitCaching"
     },
@@ -681,12 +692,18 @@ qx.Class.define("qx.io.remote.Request",
      */
     _applyProhibitCaching : function(value, old)
     {
-      if (value)
+      if (value === true || value === "no-url-params-on-post")
       {
-        // This works by making the URL unique on each request.  The actual id,
-        // "nocache" is irrelevant; it's the fact that a (usually) different date
-        // is added to the URL on each request that prevents caching.
-        this.setParameter("nocache", new Date().valueOf());
+        // If value isn't "no-url-params-on-post" or the method isn't POST ...
+        if (value !== "no-url-params-on-post" ||
+            this.getMethod() != qx.net.Http.METHOD_POST)
+        {
+          // ... then add a parameter to the URL to make it unique on each
+          // request.  The actual id, "nocache" is irrelevant; it's the fact
+          // that a (usually) different date is added to the URL on each
+          // request that prevents caching.
+          this.setParameter("nocache", new Date().valueOf());
+        }
 
         // Add the HTTP 1.0 request to avoid use of a cache
         this.setRequestHeader("Pragma", "no-cache");
--
1.5.4.3


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo remote I/O and server backends

Helder Magalhães


Derrell Lipman wrote:
>
> What do y'all think of this (untested) patch:
>
Looks great: backwards-compatibility (previous behavior) is kept and it's
possible to avoid URL changes. :-)

I'd only suggest adding a small explanation on why can this be useful, and
maybe a link to related documentation found (the original [1] or vendor's
[2]). Something like:



> As a special case, this property may be set to the string value
> "no-url-params-on-post" which will prevent the nocache parameter from
> being added to the URL if the POST method is used but will still add the
> Pragma and Cache-Control headers. This is useful if your backend is
> configured for a feature known as "mixed mode"
> (http://download.oracle.com/docs/cd/B32110_01/web.1013/b28963/concept.htm#i1005684).
>

Note that one may not want to attach a link to vendor documentation but I
simply haven't found any standard supporting it.

Regards,

 Helder Magalhães

[1]
http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b12303/concept.htm#1005692
[2]
http://download.oracle.com/docs/cd/B32110_01/web.1013/b28963/concept.htm#i1005684
--
View this message in context: http://www.nabble.com/qooxdoo-remote-I-O-and-server-backends-tp18485656p18511234.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo remote I/O and server backends

Derrell Lipman


On Thu, Jul 17, 2008 at 11:31 AM, Helder Magalhães <[hidden email]> wrote:


Derrell Lipman wrote:
>
> What do y'all think of this (untested) patch:
>
Looks great: backwards-compatibility (previous behavior) is kept and it's
possible to avoid URL changes. :-)

Ok, would you please apply and test this prettied-up patch and confirm that it works as expected.  Once you so confirm, I'll check it in.

Cheers,

Derrell
 
diff --git a/qooxdoo/frontend/framework/source/class/qx/io/remote/Request.js b/qooxdoo/frontend/framework/source/class/qx/io/remote/Request.js
index dab0b18..bbd01c3 100644
--- a/qooxdoo/frontend/framework/source/class/qx/io/remote/Request.js
+++ b/qooxdoo/frontend/framework/source/class/qx/io/remote/Request.js
@@ -263,13 +263,28 @@ qx.Class.define("qx.io.remote.Request",
     /**
      * Prohibit request from being cached.
      *
-     * Setting the value to <i>true</i> adds a parameter "nocache" to the request
-     * with a value of the current time. Setting the value to <i>false</i> removes
-     * the parameter.
+     * Setting the value to <i>true</i> adds a parameter "nocache" to the
+     * request with a value of the current time, as well as adding request
+     * headers Pragma:no-cache and Cache-Control:no-cache.
+     *
+     * Setting the value to <i>false</i> removes the parameter and request
+     * headers.
+     *
+     * As a special case, this property may be set to the string value
+     * "no-url-params-on-post" which will prevent the nocache parameter from
+     * being added to the URL if the POST method is used but will still add
+     * the Pragma and Cache-Control headers.  This is useful if your backend
+     * does nasty things like mixing parameters specified in the URL into
+     * form fields in the POST request.  (One example of this nasty behavior
+     * is known as "mixed mode" in Oracle, as described here:
+     * http://download.oracle.com/docs/cd/B32110_01/web.1013/b28963/concept.htm#i1005684)
      */
     prohibitCaching :
     {
-      check : "Boolean",
+      check : function(v)
+      {
+        return typeof v == "boolean" || v === "no-url-params-on-post";
+      },
       init : true,
       apply : "_applyProhibitCaching"
     },
@@ -681,25 +696,35 @@ qx.Class.define("qx.io.remote.Request",
      */
     _applyProhibitCaching : function(value, old)
     {
-      if (value)
+      if (! value)
       {
-        // This works by making the URL unique on each request.  The actual id,
-        // "nocache" is irrelevant; it's the fact that a (usually) different date
-        // is added to the URL on each request that prevents caching.
-        this.setParameter("nocache", new Date().valueOf());
-
-        // Add the HTTP 1.0 request to avoid use of a cache
-        this.setRequestHeader("Pragma", "no-cache");
+        this.removeParameter("nocache");
+        this.removeRequestHeader("Pragma");
+        this.removeRequestHeader("Cache-Control");
+        return;
+      }
 
-        // Add the HTTP 1.1 request to avoid use of a cache
-        this.setRequestHeader("Cache-Control", "no-cache");
+      // If value isn't "no-url-params-on-post" or this isn't a POST request
+      if (value !== "no-url-params-on-post" ||
+          this.getMethod() != qx.net.Http.METHOD_POST)
+      {
+        // ... then add a parameter to the URL to make it unique on each
+        // request.  The actual id, "nocache" is irrelevant; it's the fact
+        // that a (usually) different date is added to the URL on each request
+        // that prevents caching.
+        this.setParameter("nocache", new Date().valueOf());
       }
       else
       {
+        // Otherwise, we don't want the nocache parameer in the URL.
         this.removeParameter("nocache");
-        this.removeRequestHeader("Pragma");
-        this.removeRequestHeader("Cache-Control");
       }
+
+      // Add the HTTP 1.0 request to avoid use of a cache
+      this.setRequestHeader("Pragma", "no-cache");
+     
+      // Add the HTTP 1.1 request to avoid use of a cache
+      this.setRequestHeader("Cache-Control", "no-cache");
     },
 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo remote I/O and server backends

Derrell Lipman


On Thu, Jul 17, 2008 at 11:43 AM, Derrell Lipman <[hidden email]> wrote:


On Thu, Jul 17, 2008 at 11:31 AM, Helder Magalhães <[hidden email]> wrote:


Derrell Lipman wrote:
>
> What do y'all think of this (untested) patch:
>
Looks great: backwards-compatibility (previous behavior) is kept and it's
possible to avoid URL changes. :-)

Ok, would you please apply and test this prettied-up patch and confirm that it works as expected.  Once you so confirm, I'll check it in.

Hmmm... One more try.  If the request method property is modified, we need to re-set the prohibitCaching value. 

diff --git a/qooxdoo/frontend/framework/source/class/qx/io/remote/Request.js b/qooxdoo/frontend/framework/source/class/qx/io/remote/Request.js
index dab0b18..8e2fa8d 100644
--- a/qooxdoo/frontend/framework/source/class/qx/io/remote/Request.js
+++ b/qooxdoo/frontend/framework/source/class/qx/io/remote/Request.js
@@ -263,13 +263,28 @@ qx.Class.define("qx.io.remote.Request",
     /**
      * Prohibit request from being cached.
      *
-     * Setting the value to <i>true</i> adds a parameter "nocache" to the request
-     * with a value of the current time. Setting the value to <i>false</i> removes
-     * the parameter.
+     * Setting the value to <i>true</i> adds a parameter "nocache" to the
+     * request with a value of the current time, as well as adding request
+     * headers Pragma:no-cache and Cache-Control:no-cache.
+     *
+     * Setting the value to <i>false</i> removes the parameter and request
+     * headers.
+     *
+     * As a special case, this property may be set to the string value
+     * "no-url-params-on-post" which will prevent the nocache parameter from
+     * being added to the URL if the POST method is used but will still add
+     * the Pragma and Cache-Control headers.  This is useful if your backend
+     * does nasty things like mixing parameters specified in the URL into
+     * form fields in the POST request.  (One example of this nasty behavior
+     * is known as "mixed mode" in Oracle, as described here:
+     * http://download.oracle.com/docs/cd/B32110_01/web.1013/b28963/concept.htm#i1005684)
      */
     prohibitCaching :
     {
-      check : "Boolean",
+      check : function(v)
+      {
+        return typeof v == "boolean" || v === "no-url-params-on-post";
+      },
       init : true,
       apply : "_applyProhibitCaching"
     },
@@ -681,25 +696,35 @@ qx.Class.define("qx.io.remote.Request",
      */
     _applyProhibitCaching : function(value, old)
     {
-      if (value)
+      if (! value)
       {
-        // This works by making the URL unique on each request.  The actual id,
-        // "nocache" is irrelevant; it's the fact that a (usually) different date
-        // is added to the URL on each request that prevents caching.
-        this.setParameter("nocache", new Date().valueOf());
-
-        // Add the HTTP 1.0 request to avoid use of a cache
-        this.setRequestHeader("Pragma", "no-cache");
+        this.removeParameter("nocache");
+        this.removeRequestHeader("Pragma");
+        this.removeRequestHeader("Cache-Control");
+        return;
+      }
 
-        // Add the HTTP 1.1 request to avoid use of a cache
-        this.setRequestHeader("Cache-Control", "no-cache");
+      // If value isn't "no-url-params-on-post" or this isn't a POST request
+      if (value !== "no-url-params-on-post" ||
+          this.getMethod() != qx.net.Http.METHOD_POST)
+      {
+        // ... then add a parameter to the URL to make it unique on each
+        // request.  The actual id, "nocache" is irrelevant; it's the fact
+        // that a (usually) different date is added to the URL on each request
+        // that prevents caching.
+        this.setParameter("nocache", new Date().valueOf());
       }
       else
       {
+        // Otherwise, we don't want the nocache parameer in the URL.
         this.removeParameter("nocache");
-        this.removeRequestHeader("Pragma");
-        this.removeRequestHeader("Cache-Control");
       }
+
+      // Add the HTTP 1.0 request to avoid use of a cache
+      this.setRequestHeader("Pragma", "no-cache");
+     
+      // Add the HTTP 1.1 request to avoid use of a cache
+      this.setRequestHeader("Cache-Control", "no-cache");
     },
 
 
@@ -717,6 +742,13 @@ qx.Class.define("qx.io.remote.Request",
       } else {
         this.removeRequestHeader("Content-Type");
       }
+
+      // Re-test the prohibit caching property.  We may need to add or remove
+      // the "nocache" parameter.  We explicitly call the _apply method since
+      // it wouldn't be called normally when setting the value to its already
+      // existant value.
+      var prohibitCaching = this.getProhibitCaching();
+      this._applyProhibitCaching(prohibitCaching, prohibitCaching);
     },
 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo remote I/O and server backends

Helder Magalhães
In reply to this post by Derrell Lipman


Derrell Lipman wrote:
>
> Ok, would you please apply and test this prettied-up patch and confirm
> that
> it works as expected.  Once you so confirm, I'll check it in.
>
Does "you" means "me" or the plural form ("qooxdoo users/developers")? :-P

Unfortunately I (most likely) won't be able to test this within the next few
weeks. :-| Nevertheless, the patch looks fine and (only by reviewing it) I'm
pretty confident that (the second version) will work without disrupting
anything. :-)

If you decide not applying the patch until more tests are performed, why not
update the original patch within the bug report [1], to be sure it won't get
lost? ;-)

Regards,

 Helder Magalhães

[1] http://bugzilla.qooxdoo.org/show_bug.cgi?id=1017
--
View this message in context: http://www.nabble.com/qooxdoo-remote-I-O-and-server-backends-tp18485656p18531395.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qooxdoo remote I/O and server backends

Derrell Lipman
On Fri, Jul 18, 2008 at 11:08 AM, Helder Magalhães <[hidden email]> wrote:


Derrell Lipman wrote:
>
> Ok, would you please apply and test this prettied-up patch and confirm
> that
> it works as expected.  Once you so confirm, I'll check it in.
>
Does "you" means "me" or the plural form ("qooxdoo users/developers")? :-P

Yes, "you" means "you". :-)  Asking for a whole generic group of people to test this is doomed to failure, so I prefer to assign it to the person who really wants this bug fixed. :-)

If you decide not applying the patch until more tests are performed, why not
update the original patch within the bug report [1], to be sure it won't get
lost? ;-)

I've added the patch to the bug.

Derrell
 

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel