[Zope3-Users] Re: [Zope3-dev] Freeze approaching quickly

[Julien Anguenot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Fulton wrote:
>>> with October winding down, the freeze on the trunk is coming quickly.
>>> So, if you have any outstanding work, now is the time to get it done.
>>> During the last week I have monitored the proposals and branches a
>>> bit and I think most people are done with their work. 
>>
>>
>> [...]
>>
>>> Did I miss anyone? Now is the time to speak up!
>>
>>
>>
>> yes, I'd like to see the "Better XML support for PT" proposal as well :
>>
>> http://svn.zope.org/Zope3/branches/fdrake-anguenot_better_xml_support_for_pt/
>>
>> http://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/BetterXMLSupportForPageTemplates
>>
>>
>> I'll take time to finish the remaining issues around this in the
>> following days and we'll be able to discuss it after this.
>>
>> Is it ok for everybody ?
> 
> 
> I think this is too risky for this release:
> 
> 1. This change seems to be pretty controversial.  There is a lot of
>    fear that this will cause browser compatability problems.  I think
>    this fear can only be addressed by an alpha release and it's too
>    late for that for the december Zope releases.

We did think hard on browser issues (especially IE ones) avoiding to
require the XML processing header for PT XML processing using a new 'IE
problem aware' sniffer that detects a PT as an XML document with
different approaches. I think, it was the only serious thread related to
browser compatibility around this work.

Behavior in the branch :

 - .xpt extension -> XML processing (to avoid sniffing and thus be
quicker) (this may be controversial as well)
 - xmlns declarations -> XML processing (for IE)
 - XML processing header -> XML processing (current trunk behavior)

The more controversial point is the deprecation of HTML 4 as *input* for
PT. xhtml will be required so that we can avoid all this HTML processing
mess and especially all the iencoding ssues around. It will simplify the
page template machinery big time and avoid costly internal operations at
the same time. The compatibility will be kept for 2 major releases (as
usual)

As well, the *output* will be xhtml (at least) in every case after this
changes.

> 
> 2. I get the impression from talking to Fred that there is still a lot
>    of work required to land this and that a significant amount of
>    his time would likely be required.   I'm worrid that this could
>    be a major source of instability and I think we have enough of
>    those already.

We're having mostly encoding issues at this time 'cause of the HTML
processing. I already started to address this problem o

Fred, what is the status of the bytecode generation ? Is there more that
only encoding problems left ?

> 
> I suggest the following:
> 
> - You keep working on your branch and get it to the point that it is
>   *stable* and ready to merge.

ok

> 
> - Soon after the 3.2 release branch is made in early November, you
>   merge your stable branch to the trunk and we'll make a 3.3 alpha release
>   that people can use to try out this change.  We'll let it be known
>   that the change will be included in 3.3 unless people discover serious
>   client-compatibility problems created by the change.  You could use this
>   release or the trunk for your xmlforms experiments.
> 

right. I'm fine with this. We will be more on the safe side :)

	J.

- --
Julien Anguenot | Nuxeo R&D (Paris, France)
CPS Platform : http://www.cps-project.org
Zope3 / ECM   : http://www.z3lab.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFDYPHJGhoG8MxZ/pIRAjlJAJ9uwj5YDTuxhErfgwpf1SsDv04nigCeNs/J
11YknMwiS47Rcrwv8krdUiM=
=4fn1
-----END PGP SIGNATURE-----