Hey,

> My opinion has changed. I believe we should be fully standards-compliant by 
> default. That applies to both the missing date functionality that we've 
> kludged in, as well as server data. The loss of each of these will be a large 
> burden on many applications, but in the long run, I think that 
> standardization outweighs the usefulness of these features.

Thats exactly my point and good to hear that you are with me.

> 
> We must, until at least version 2.0 retain the capability of using the now 
> "qooxdoo standard" additional features, via a mixin or other mechanism. That 
> functionality has been in the code for many years, and there are too many 
> potential users of it to simply drop it in any 1.x version. It will be a 
> significantly major and obtrusive change that does not belong in anything 
> other than a major version number (1st digit) release.

We just deprecated the default JSON parsing and stringifying behavior of the 
qx.util.JSON to move from the old date stringifying to the default JSON way. 
But we managed to keep both behaviors available so users can choose to use the 
old way without any deprecation warning. I think thats a good way because none 
has to change his legacy apps as long as we don't remove the stuff (which i 
don't plan to). But the default case will change to encurage the users not to 
use the special qooxdoo date stuff.

Best,
Martin


------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to