You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@yahoo.de> on 2004/11/01 19:28:38 UTC
Switching rhino implementation
I'm going to integrate the new Rhino+cont implementation in the next few days
and plan to support the old and the new implementation, at least in 2.1. I
wonder ...
1. What do we want to call the new implementation (I mean the language
name in <map:flow language="???"/>).
a.) call the new implementation "javascript" and tell our users
that if they have problems they can use "javascript-legacy"
or some other alternative name for the old implementation?
If so, shouldn't I wait for 2.1.6 and do the integration then?
b.) keep "javascript" as the name of the old implementation and
find a new name for the new implementation?
2. If we deprecate the old flowscript implementation in 2.1 - do we have to
keep it in 2.2 or can I remove it?
I would wait with switching to the new flowscript implementation until the
release of 2.1.6 Then we have a few months to test it in branch and trunk and if
everything goes well I would deprecate the old one and rename it to
"javascript-legacy" and the new impl should be the default language.
In 2.2 I would remove the old implementation completly.
WDOT?
--
Reinhard
Re: Switching rhino implementation
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi:
First of all congratulations to Igor Bukanov from the Mozilla community,
to you and to the other people that make this posible!
To answer your question is hard because:
1-We have nearly 1 month waiting for the 2.1.6 release.
2-Same as Ralph: If the changes don't break beackward compatibility go
ahead and make (1.a), if not, I think we can also release with something
like:
<map:flow language="js"/> <!-- The new implementation -->
Of course this tag will be just for the 2.1.6 version and then later we
can merge both, so in 2.2 will be the same:
<map:flow language="javascript"/> or
<map:flow language="js"/>
In the case of (2) I see to situations based on the backward compatibility
of the new rhino:
2.A- The new rhino is backward compatible: We can remove the old
implementation.
2.B. The new rhino is NOT backward compatible: We need to deprecate the
old one and mantain both libraries.
My POV is we need to move to the new library as soon as posible. I really
will like to see the Cocoon flow engine using the new JS 2.0 features! ;-)
Best Regards,
Antonio Gallardo
Reinhard Poetz dijo:
>
> I'm going to integrate the new Rhino+cont implementation in the next few
> days
> and plan to support the old and the new implementation, at least in 2.1. I
> wonder ...
>
> 1. What do we want to call the new implementation (I mean the language
> name in <map:flow language="???"/>).
>
> a.) call the new implementation "javascript" and tell our users
> that if they have problems they can use "javascript-legacy"
> or some other alternative name for the old implementation?
>
> If so, shouldn't I wait for 2.1.6 and do the integration then?
>
> b.) keep "javascript" as the name of the old implementation and
> find a new name for the new implementation?
>
> 2. If we deprecate the old flowscript implementation in 2.1 - do we have
> to
> keep it in 2.2 or can I remove it?
>
>
> I would wait with switching to the new flowscript implementation until the
> release of 2.1.6 Then we have a few months to test it in branch and trunk
> and if
> everything goes well I would deprecate the old one and rename it to
> "javascript-legacy" and the new impl should be the default language.
>
> In 2.2 I would remove the old implementation completly.
>
> WDOT?
>
> --
> Reinhard
>
Re: Switching rhino implementation
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
> Vadim Gritsenko wrote:
>
>> Ralph Goers wrote:
>>
>>> Is the new implementation compatible (from the user's perspective) with
>>> the old version? If so, in my opinion you can just switch it now. If
>>> changes will be required then a notice should go out with 2.1.6 in the
>>> release notes and the switch would occur in 2.1.7.
>>
>>
>>
>> IIRC, there is an incompatibility - there is no "catch {}" construct
>> in official rhino.
>
>
> Thanks for the info. Now that you mention it I do remember seeing
> something mentioned about that. What is the recommended approach for
> users to handle this?
You would have to rewrite your flowscripts whenever you use catch(return),
catch(continue) and catch(break).
--
Reinhard
Re: Switching rhino implementation
Posted by Ralph Goers <Ra...@dslextreme.com>.
Vadim Gritsenko wrote:
> Ralph Goers wrote:
>
>> Is the new implementation compatible (from the user's perspective) with
>> the old version? If so, in my opinion you can just switch it now. If
>> changes will be required then a notice should go out with 2.1.6 in the
>> release notes and the switch would occur in 2.1.7.
>
>
> IIRC, there is an incompatibility - there is no "catch {}" construct
> in official rhino.
Thanks for the info. Now that you mention it I do remember seeing
something mentioned about that. What is the recommended approach for
users to handle this?
Ralph
Re: Switching rhino implementation
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ralph Goers wrote:
> Is the new implementation compatible (from the user's perspective) with
> the old version? If so, in my opinion you can just switch it now. If
> changes will be required then a notice should go out with 2.1.6 in the
> release notes and the switch would occur in 2.1.7.
IIRC, there is an incompatibility - there is no "catch {}" construct in official
rhino.
> Ralph
>
>
> Reinhard Poetz said:
>
>>I'm going to integrate the new Rhino+cont implementation in the next few
>>days
>>and plan to support the old and the new implementation, at least in 2.1. I
>>wonder ...
>>
>>1. What do we want to call the new implementation (I mean the language
>> name in <map:flow language="???"/>).
>>
>> a.) call the new implementation "javascript" and tell our users
>> that if they have problems they can use "javascript-legacy"
>> or some other alternative name for the old implementation?
Ok.
>> If so, shouldn't I wait for 2.1.6 and do the integration then?
Fine with me. Integration after 2.1.6 allows making 2.1.6 release sooner.
>> b.) keep "javascript" as the name of the old implementation and
>> find a new name for the new implementation?
>>
>>2. If we deprecate the old flowscript implementation in 2.1 - do we have
>>to
>> keep it in 2.2 or can I remove it?
Remove it.
>>I would wait with switching to the new flowscript implementation until the
>>release of 2.1.6 Then we have a few months to test it in branch and trunk
>>and if
>>everything goes well I would deprecate the old one and rename it to
>>"javascript-legacy" and the new impl should be the default language.
I'd integrate new one and deprecate old one as soon as 2.1.6 is out.
>>In 2.2 I would remove the old implementation completly.
Agreed.
Vadim
>>Reinhard
Re: Switching rhino implementation
Posted by Ralph Goers <Ra...@dslextreme.com>.
Is the new implementation compatible (from the user's perspective) with
the old version? If so, in my opinion you can just switch it now. If
changes will be required then a notice should go out with 2.1.6 in the
release notes and the switch would occur in 2.1.7.
Ralph
Reinhard Poetz said:
>
> I'm going to integrate the new Rhino+cont implementation in the next few
> days
> and plan to support the old and the new implementation, at least in 2.1. I
> wonder ...
>
> 1. What do we want to call the new implementation (I mean the language
> name in <map:flow language="???"/>).
>
> a.) call the new implementation "javascript" and tell our users
> that if they have problems they can use "javascript-legacy"
> or some other alternative name for the old implementation?
>
> If so, shouldn't I wait for 2.1.6 and do the integration then?
>
> b.) keep "javascript" as the name of the old implementation and
> find a new name for the new implementation?
>
> 2. If we deprecate the old flowscript implementation in 2.1 - do we have
> to
> keep it in 2.2 or can I remove it?
>
>
> I would wait with switching to the new flowscript implementation until the
> release of 2.1.6 Then we have a few months to test it in branch and trunk
> and if
> everything goes well I would deprecate the old one and rename it to
> "javascript-legacy" and the new impl should be the default language.
>
> In 2.2 I would remove the old implementation completly.
>
> WDOT?
>
> --
> Reinhard
>
>
Re: Switching rhino implementation
Posted by Ralph Goers <Ra...@dslextreme.com>.
Bertrand Delacretaz said:
>
> +1, there's no hurry I think, better switch after the release to test
> the new implementation a bit more.
Stability is extremely important and should not be compromised. That
said, if this change is backward compatible I view getting this in as
extremely important.
I have another question though. Will we be using a released version of
Rhino or will it be a snapshot?
Ralph
Re: Switching rhino implementation
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> Leszek Gawron wrote:
>
>> Reinhard Poetz wrote:
>>
>>> Thank you guys.
>>>
>>> I'm going to replace the old implementation by the new one in trunk.
>>> In branch I will wait for the new release and rename the old language
>>> "javascript-2.1.6" which indicates that this is the former
>>> implementation. The new implementation will be called "javascript".
>>> This way most of our users will switch to the new implementation
>>> without noticing it. If they have problems they can either rewrite
>>> their catch() statements or change the language to "javascript-2.1.6".
>>>
>> Is there any replacement for catch() functionality in new implementation?
>>
>
> Igor explains the differences here:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109528520325331&w=2
>
Thank you. From what I see in this mail new implementation still allows for
cleanup code after continuation has been created but does not allow for
automatic resource fetching ( catch( continue ) ).
<quote>
var pool = ...;
function someFunction() {
var conn = pool.getConnection();
...
catch (break) {
conn.close();
conn = null;
}
catch (continue) {
conn = pool.getConnection();
}
}
with the patch would like:
var pool = ...;
function someFunction() {
var conn = null;
try {
if (conn == null) {
conn = pool.getConnection();
}
...
} finally {
conn.close();
conn = null;
}
}
</quote>
so now you have to fetch the connection yourself each time the continuation is
resumed right? Is there any chance for porting that feature into new
implementation?
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox 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: Switching rhino implementation
Posted by Antonio Gallardo <ag...@agssa.net>.
Reinhard Poetz dijo:
> Igor explains the differences here:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109528520325331&w=2
Please wikify that! ;-)
Best Regards,
Antonio Gallardo
Re: Switching rhino implementation
Posted by Reinhard Poetz <re...@apache.org>.
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>
>> Thank you guys.
>>
>> I'm going to replace the old implementation by the new one in trunk.
>> In branch I will wait for the new release and rename the old language
>> "javascript-2.1.6" which indicates that this is the former
>> implementation. The new implementation will be called "javascript".
>> This way most of our users will switch to the new implementation
>> without noticing it. If they have problems they can either rewrite
>> their catch() statements or change the language to "javascript-2.1.6".
>>
> Is there any replacement for catch() functionality in new implementation?
>
Igor explains the differences here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109528520325331&w=2
--
Reinhard
Re: Switching rhino implementation
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> Thank you guys.
>
> I'm going to replace the old implementation by the new one in trunk. In
> branch I will wait for the new release and rename the old language
> "javascript-2.1.6" which indicates that this is the former
> implementation. The new implementation will be called "javascript". This
> way most of our users will switch to the new implementation without
> noticing it. If they have problems they can either rewrite their catch()
> statements or change the language to "javascript-2.1.6".
>
Is there any replacement for catch() functionality in new implementation?
--
Leszek Gawron lgawron@mobilebox.pl
Project Manager MobileBox 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: Switching rhino implementation
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
> Thank you guys.
>
> I'm going to replace the old implementation by the new one in trunk.
> In branch I will wait for the new release and rename the old language
> "javascript-2.1.6" which indicates that this is the former
> implementation. The new implementation will be called "javascript".
> This way most of our users will switch to the new implementation
> without noticing it. If they have problems they can either rewrite
> their catch() statements or change the language to "javascript-2.1.6".
>
Don't forget to publish something in the release notes for 2.1.6.
Re: Switching rhino implementation
Posted by Reinhard Poetz <re...@apache.org>.
Bertrand Delacretaz wrote:
> Le 1 nov. 04, à 19:28, Reinhard Poetz a écrit :
>
>> ...I would wait with switching to the new flowscript implementation
>> until the release of 2.1.6 Then we have a few months to test it in
>> branch and trunk and if everything goes well I would deprecate the old
>> one and rename it to "javascript-legacy" and the new impl should be
>> the default language
>>
>> In 2.2 I would remove the old implementation completly...
>
>
> +1, there's no hurry I think, better switch after the release to test
> the new implementation a bit more.
>
> Except maybe using "javascript-2.1.6" instead of "javascript-legacy", in
> order to avoid "javascript-legacy-square" if there is another such move
> down the road ;-)
Thank you guys.
I'm going to replace the old implementation by the new one in trunk. In branch I
will wait for the new release and rename the old language "javascript-2.1.6"
which indicates that this is the former implementation. The new implementation
will be called "javascript". This way most of our users will switch to the new
implementation without noticing it. If they have problems they can either
rewrite their catch() statements or change the language to "javascript-2.1.6".
--
Reinhard
Re: Switching rhino implementation
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 1 nov. 04, à 19:28, Reinhard Poetz a écrit :
> ...I would wait with switching to the new flowscript implementation
> until the release of 2.1.6 Then we have a few months to test it in
> branch and trunk and if everything goes well I would deprecate the old
> one and rename it to "javascript-legacy" and the new impl should be
> the default language
>
> In 2.2 I would remove the old implementation completly...
+1, there's no hurry I think, better switch after the release to test
the new implementation a bit more.
Except maybe using "javascript-2.1.6" instead of "javascript-legacy",
in order to avoid "javascript-legacy-square" if there is another such
move down the road ;-)
-Bertrand
Re: Switching rhino implementation
Posted by Ralph Goers <Ra...@dslextreme.com>.
Pier Fumagalli said:
> On 1 Nov 2004, at 23:22, Stefano Mazzocchi wrote:
>>
>> Jesus, what happened to the release early and often paradigm? 2.1.6
>> has been in the making foreeeeeeeeever. Can we get that sucker out of
>> the door or we have to fix all the bugs before we do? and that will
>> never happen anyway.
>
> I tend to agree w/ Stefano... I need to run VNUNET on a mix of 2.1.5
> and a bunch of patches that have only been committed to HEAD :-(
I guess this is as good a time as any to bring this up. I'd like to
suggest that it is time to schedule a release date for 2.1.6. Typically,
we seem to be doing it shortly after a first friday, which is just a few
days away. Hopefully, I'll actually be able to commit by then as I have a
few things waiting in my queue. However, I don't know when a good time
will be for our release manager to do it.
Ralph
RE: Release 2.1.6 (was: Re: Switching rhino implementation)
Posted by Carsten Ziegeler <cz...@apache.org>.
Antonio Gallardo wrote:
>
> The task is "easy", we need to merge only few files before
> the release:
>
> http://wiki.apache.org/cocoon/MergingBranches
>
> I think after that we can finally release. ;-)
>
> WDYT?
>
Exactly my thoughts - although I have the feeling that some things
have only been added to trunk which should also have gone to 2.1.x...
Anyways, it seems that we are not that interested in merging everything
back from the trunk to the branch, so we can even release without
merging everything. I will have some time next friday to prepare
a release candidate, so I suggest we use whatever is available next
friday.
If noone objects I will put it up to a public place next friday,
we can test it and then release one week later.
Carsten
Release 2.1.6 (was: Re: Switching rhino implementation)
Posted by Antonio Gallardo <ag...@agssa.net>.
Pier Fumagalli dijo:
> On 1 Nov 2004, at 23:22, Stefano Mazzocchi wrote:
>
>> Reinhard Poetz wrote:
>>
>>> I'm going to integrate the new Rhino+cont implementation in the next
>>> few days and plan to support the old and the new implementation, at
>>> least in 2.1. I wonder ...
>>
>> Jesus, what happened to the release early and often paradigm? 2.1.6
>> has been in the making foreeeeeeeeever. Can we get that sucker out of
>> the door or we have to fix all the bugs before we do? and that will
>> never happen anyway.
>
> I tend to agree w/ Stefano... I need to run VNUNET on a mix of 2.1.5
> and a bunch of patches that have only been committed to HEAD :-(
The task is "easy", we need to merge only few files before the release:
http://wiki.apache.org/cocoon/MergingBranches
I think after that we can finally release. ;-)
WDYT?
Best Regards,
Antonio Gallardo.
Re: Switching rhino implementation
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 1 Nov 2004, at 23:22, Stefano Mazzocchi wrote:
> Reinhard Poetz wrote:
>
>> I'm going to integrate the new Rhino+cont implementation in the next
>> few days and plan to support the old and the new implementation, at
>> least in 2.1. I wonder ...
>
> Jesus, what happened to the release early and often paradigm? 2.1.6
> has been in the making foreeeeeeeeever. Can we get that sucker out of
> the door or we have to fix all the bugs before we do? and that will
> never happen anyway.
I tend to agree w/ Stefano... I need to run VNUNET on a mix of 2.1.5
and a bunch of patches that have only been committed to HEAD :-(
Pier
Re: Switching rhino implementation
Posted by Stefano Mazzocchi <st...@apache.org>.
Reinhard Poetz wrote:
>
> I'm going to integrate the new Rhino+cont implementation in the next few
> days and plan to support the old and the new implementation, at least in
> 2.1. I wonder ...
Jesus, what happened to the release early and often paradigm? 2.1.6 has
been in the making foreeeeeeeeever. Can we get that sucker out of the
door or we have to fix all the bugs before we do? and that will never
happen anyway.
shrug.
--
Stefano.