Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Vadim Gritsenko wrote: Leszek Gawron wrote: Previously we have discussed about three continuations manager work modes: - standard (current functionality) - continuations invalidated along with session, still the continuation is reachable from other sessions (or no session at all) - fully isolated. only the session that created the continuation can access it. Thing is after a while I still do not see a use case for a second case where continuations would be invalidated with user session but still accessibe for everyone (of course before invalidation). So I have changed the continuations manager to support only 1st and 3rd case. about 2nd: YAGNI (thanks Stefano for new cool phrase :)) I thought 1st was older functionality, 2nd was current functionality (with sitemap isolation, not sessions). 2nd as you formulated it is not needed, 100% agreement here. Vadim Not quite. Sitemap isolation is implied for EVERY case. If the user has a site that he/she is not able to refactor the old behaviour may be enabled by setting continuation-sharing-bug-compatible to true. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Antonio Gallardo wrote: On Jue, 9 de Diciembre de 2004, 2:49, Leszek Gawron dijo: Bertrand Delacretaz wrote: Le 9 déc. 04, à 09:21, Leszek Gawron a écrit : ...By the way: it is a little bit different on win32. Some tools detect utf encoding by checking for BOM. If there is none - ANSI encoding is assumed... AFAIU this is ok for 16-bit based encodings, not for UTF-8. http://www.xencraft.com/resources/unicodebom.html ... M$ again. This is the standard: http://www.zvon.org/tmRFC/RFC3023/Output/chapter8.html#sub1 :-D No, it's not. The standard is: http://www.w3c.org/TR/2004/REC-xml11-20040204/#NT-XMLDecl XML *must* start with '?xml'. So no MS junk of any kind is allowed. Please don't use notepad - vim and far both have syntax highlight and do not write boms of any kind :) Vadim
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Vadim Gritsenko wrote: Antonio Gallardo wrote: On Jue, 9 de Diciembre de 2004, 2:49, Leszek Gawron dijo: Bertrand Delacretaz wrote: Le 9 déc. 04, à 09:21, Leszek Gawron a écrit : ...By the way: it is a little bit different on win32. Some tools detect utf encoding by checking for BOM. If there is none - ANSI encoding is assumed... AFAIU this is ok for 16-bit based encodings, not for UTF-8. http://www.xencraft.com/resources/unicodebom.html ... M$ again. This is the standard: http://www.zvon.org/tmRFC/RFC3023/Output/chapter8.html#sub1 :-D No, it's not. The standard is: http://www.w3c.org/TR/2004/REC-xml11-20040204/#NT-XMLDecl XML *must* start with '?xml'. So no MS junk of any kind is allowed. Please don't use notepad - vim and far both have syntax highlight and do not write boms of any kind :) I am not using notepad :). Apparently even sophisticated win32 text editors (like my favourive UltraEdit) support UTF-8 BOMs. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Leszek Gawron wrote: Previously we have discussed about three continuations manager work modes: - standard (current functionality) - continuations invalidated along with session, still the continuation is reachable from other sessions (or no session at all) - fully isolated. only the session that created the continuation can access it. Thing is after a while I still do not see a use case for a second case where continuations would be invalidated with user session but still accessibe for everyone (of course before invalidation). So I have changed the continuations manager to support only 1st and 3rd case. about 2nd: YAGNI (thanks Stefano for new cool phrase :)) I thought 1st was older functionality, 2nd was current functionality (with sitemap isolation, not sessions). 2nd as you formulated it is not needed, 100% agreement here. Vadim
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Leszek Gawron wrote: Vadim Gritsenko wrote: Leszek Gawron wrote: Previously we have discussed about three continuations manager work modes: - standard (current functionality) - continuations invalidated along with session, still the continuation is reachable from other sessions (or no session at all) - fully isolated. only the session that created the continuation can access it. Thing is after a while I still do not see a use case for a second case where continuations would be invalidated with user session but still accessibe for everyone (of course before invalidation). So I have changed the continuations manager to support only 1st and 3rd case. about 2nd: YAGNI (thanks Stefano for new cool phrase :)) I thought 1st was older functionality, 2nd was current functionality (with sitemap isolation, not sessions). 2nd as you formulated it is not needed, 100% agreement here. Not quite. Sitemap isolation is implied for EVERY case. Currently - yes. But not at the time when discussion was made. I was referring to the older discussion. If the user has a site that he/she is not able to refactor the old behaviour may be enabled by setting continuation-sharing-bug-compatible to true. I know. Vadim
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Bertrand Delacretaz wrote: Le 9 déc. 04, à 01:03, Leszek Gawron a écrit : ... +?xml version=1.0 encoding=UTF-8? ... This is BOM (byte ordering mark). It is being written by some of xml editors to the beginning of the multibyte encoded (i.e. utf-8) xml file. The file I commited is a valid xml. Check in any xml editor/browser... BOM has no meaning for UTF-8, see http://www.unicode.org/unicode/faq/utf_bom.html#BOM It is certainly better *not* to use it, to avoid any confusion. On unixish OSes, many tools check the first four bytes of a file and expect them to be ?xm -Bertrand OK. No problem. By the way: it is a little bit different on win32. Some tools detect utf encoding by checking for BOM. If there is none - ANSI encoding is assumed. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
On Jue, 9 de Diciembre de 2004, 2:21, Leszek Gawron dijo: By the way: it is a little bit different on win32. Some tools detect utf encoding by checking for BOM. If there is none - ANSI encoding is assumed. then switch to Linux! ;-) Best Regards, Antonio Gallardo
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Le 9 déc. 04, à 09:21, Leszek Gawron a écrit : ...By the way: it is a little bit different on win32. Some tools detect utf encoding by checking for BOM. If there is none - ANSI encoding is assumed... AFAIU this is ok for 16-bit based encodings, not for UTF-8. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Bertrand Delacretaz wrote: Le 9 déc. 04, à 09:21, Leszek Gawron a écrit : ...By the way: it is a little bit different on win32. Some tools detect utf encoding by checking for BOM. If there is none - ANSI encoding is assumed... AFAIU this is ok for 16-bit based encodings, not for UTF-8. -Bertrand http://www.xencraft.com/resources/unicodebom.html quote Even though UTF-8 does not need a BOM to indicate endianness, Microsoft Notepad began prepending a BOM to its UTF-8 text files. Actually, it is a conversion of U+FEFF to an encoding as UTF-8 serialized bytes: EF BB BF (or in 4GL: CHR(15711167)). There is some value in the BOM being used as a file signature, indicating the plain text file is encoded as Unicode UTF-8, as opposed to some other code page. That particular 3-byte sequence is unlikely to represent data in any other code page, given the text is supposed to be human readable in some language. However, there is some small possibility that it represents some string in some code page... Because Microsoft did it, and there is so much Notepad data out there, the UTF-8 BOM became a de facto standard and then a de jure standard. (Although the BOM is optional.) /quote M$ again. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
On Jue, 9 de Diciembre de 2004, 2:49, Leszek Gawron dijo: Bertrand Delacretaz wrote: Le 9 déc. 04, à 09:21, Leszek Gawron a écrit : ...By the way: it is a little bit different on win32. Some tools detect utf encoding by checking for BOM. If there is none - ANSI encoding is assumed... AFAIU this is ok for 16-bit based encodings, not for UTF-8. -Bertrand http://www.xencraft.com/resources/unicodebom.html quote Even though UTF-8 does not need a BOM to indicate endianness, Microsoft Notepad began prepending a BOM to its UTF-8 text files. Actually, it is a conversion of U+FEFF to an encoding as UTF-8 serialized bytes: EF BB BF (or in 4GL: CHR(15711167)). There is some value in the BOM being used as a file signature, indicating the plain text file is encoded as Unicode UTF-8, as opposed to some other code page. That particular 3-byte sequence is unlikely to represent data in any other code page, given the text is supposed to be human readable in some language. However, there is some small possibility that it represents some string in some code page... Because Microsoft did it, and there is so much Notepad data out there, the UTF-8 BOM became a de facto standard and then a de jure standard. (Although the BOM is optional.) /quote M$ again. This is the standard: http://www.zvon.org/tmRFC/RFC3023/Output/chapter8.html#sub1 :-D Best Regards, Antonio Gallardo.
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Le 9 déc. 04, à 09:49, Leszek Gawron a écrit : ... Because Microsoft did it, and there is so much Notepad data out there, the UTF-8 BOM became a de facto standard and then a de jure standard. (Although the BOM is optional.).. hmm...not sure if notepad is the kind of reference that we want to use here ;-) Anyway, I think most or all our XML files are UTF-8 with no BOM, so it's probably not a good idea to change. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Bertrand Delacretaz wrote: Le 9 déc. 04, à 09:49, Leszek Gawron a écrit : ... Because Microsoft did it, and there is so much Notepad data out there, the UTF-8 BOM became a de facto standard and then a de jure standard. (Although the BOM is optional.).. hmm...not sure if notepad is the kind of reference that we want to use here ;-) Anyway, I think most or all our XML files are UTF-8 with no BOM, so it's probably not a good idea to change. It is not only the problem of notepad. At least 2 tools I use (UltraEdit and Araxis Merge) follow the same logic. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
[EMAIL PROTECTED] wrote: Author: lgawron Date: Wed Dec 8 03:47:12 2004 New Revision: 111262 URL: http://svn.apache.org/viewcvs?view=revrev=111262 Log: implement 2 modes of work for continuations manager: - standard, as it was up till now - secure in which continuations are bound to session. Only the session that created a continuation can invoke it. All continuations bound to session are invalidated when the session ifself gets invalidated. This mode is for those users who build web applications protected with authentification. Modified: cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/ContinuationsManagerImpl.java cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/WebContinuation.java cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf Previously we have discussed about three continuations manager work modes: - standard (current functionality) - continuations invalidated along with session, still the continuation is reachable from other sessions (or no session at all) - fully isolated. only the session that created the continuation can access it. Thing is after a while I still do not see a use case for a second case where continuations would be invalidated with user session but still accessibe for everyone (of course before invalidation). So I have changed the continuations manager to support only 1st and 3rd case. about 2nd: YAGNI (thanks Stefano for new cool phrase :)) -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Leszek Gawron wrote: about 2nd: YAGNI (thanks Stefano for new cool phrase :)) I guess it was Sylvain that introduced me to it, so thank him :-) -- Stefano.
RE: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
http://c2.com/cgi/wiki?YouArentGonnaNeedIt -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 08, 2004 4:53 PM To: [EMAIL PROTECTED] Subject: Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF Leszek Gawron wrote: about 2nd: YAGNI (thanks Stefano for new cool phrase :)) I guess it was Sylvain that introduced me to it, so thank him :-) -- Stefano.
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Antonio Gallardo wrote: On Mie, 8 de Diciembre de 2004, 5:47, [EMAIL PROTECTED] dijo: Author: lgawron Date: Wed Dec 8 03:47:12 2004 New Revision: 111262 URL: http://svn.apache.org/viewcvs?view=revrev=111262 ... cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf --- cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf(original) +++ cocoon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconfWed Dec 8 03:47:12 2004 @@ -1,4 +1,4 @@ -?xml version=1.0 encoding=UTF-8? +?xml version=1.0 encoding=UTF-8? ^ | What is that? Please, be carefull next time. :-D Best Regards, Antonio Gallardo. This is BOM (byte ordering mark). It is being written by some of xml editors to the beginning of the multibyte encoded (i.e. utf-8) xml file. The file I commited is a valid xml. Check in any xml editor/browser. The question is do we allow BOMs in xml files? If not I will have to look for a way to disable the feature for cocoon files. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: r111262 - in cocoon/branches/BRANCH_2_1_X/src: java/org/apache/cocoon/components/flow webapp/WEB-INF
Le 9 déc. 04, à 01:03, Leszek Gawron a écrit : ... +?xml version=1.0 encoding=UTF-8? ... This is BOM (byte ordering mark). It is being written by some of xml editors to the beginning of the multibyte encoded (i.e. utf-8) xml file. The file I commited is a valid xml. Check in any xml editor/browser... BOM has no meaning for UTF-8, see http://www.unicode.org/unicode/faq/utf_bom.html#BOM It is certainly better *not* to use it, to avoid any confusion. On unixish OSes, many tools check the first four bytes of a file and expect them to be ?xm -Bertrand smime.p7s Description: S/MIME cryptographic signature
