cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Oliver" <coli...@SeeBeyond.com>
Subject RE: Syncing rhino
Date Mon, 23 Jun 2003 23:13:40 GMT
Hi Gianugo,

Your experience is the same as mine. The Rhino core needs to be
refactored to be extensible in order to allow multiple interpreters such
as the one that supports continuations.

I have seen the BEA XML scripting code and they simply hacked their
stuff right into the Rhino core (not even as a separate package), so I
doubt that it will ever be integrated into the Mozilla cvs either.

I'm willing to help, but to make this happen we really need to work
closely with the Rhino developers and redesign the core interfaces to
allow pluggability.

Regards,
Chris

-----Original Message-----
From: Gianugo Rabellino [mailto:gianugo@apache.org] 
Sent: Monday, June 23, 2003 6:35 AM
To: cocoon-dev@xml.apache.org
Subject: Syncing rhino


I feel that guranteeing a future to the flow has to go through syncing 
our patched Rhino version with the official one. If we are unable to 
lobby them and let it go through their main CVS (which would be of 
course the best solution), at a very least we should maintain a set of 
patches and keep them in sync with their latest code (I'm afraid that 
Gump can't do that unfortunately...).

This is for a number of reasons: not only we might want bugfixes (think 
about security holes...), but we might also want enhancement (the next 
big thing in ECMAScript might be native XML support, with XPath and the 
like, go figure...).

Today I wanted to have a look on how much work has to be done to sync 
the current version with the rhino current CVS. Under the assumption 
that it was enough to have org.mozilla.javascript.continuations compile 
with the latest rhino, I played with cocoondev and mozilla's CVS. So far

I'm having mixed results: I was able to drop the errors from 651 to 76, 
which in itself might look good, but this was only possible by paying a 
quite high price. The Mozilla core stuff is not designed for 
extendability: almost everything is final and private. I was wondering 
if Christopher had to hack his way through as I did today, by changing 
visibility all the way across the Mozilla code.

This is a huge problem in itself, but I won't despair... at a very least

we might be able to keep all the stuff as a set of patches. Now, two 
questions:

1. do you think that changing the core Mozilla code is something we 
should really do (and, Christopher, has it been done in the past)? It's 
not about logic, just about making privates protected or public, yet I 
don't quite feel it's the way to go. Suggestions?

2. I'm wondering if there is someone interested in joining this effort: 
I'm not a rhino or flow guru, and I'm having quite an hard time figuring

out what to do next. If so, how can we manage to join forces?

LMK,

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
     (Now blogging at: http://blogs.cocoondev.org/gianugo/)


Mime
View raw message