On Nov 27, 2009, at 5:14 AM, Gonzalo Aguilar Delgado wrote:
First of all... I know that this proposition doubles work...
Double work, double bugs, and then when you decide to go off and do
something else when you get bored with this project, double
maintenance for me. And not only a zero feature gain, but a negative
feature gain since the work you could be doing on features (developed
in collaboration between all developers) is instead "wasted" (I say
wasted from the team POV) on duplicating everything. We are a small
team.
Sorry, thats just my POV, and maybe some fear from getting burnt in
the past by people who are gung-ho one day, and disappear the next. I
try to put the project quality first.
But can at least leave door open for other AJAX toolkits?
Point taken. What I will do is investigate introducing a Jetspeed
Javascript API layer, so all high level Javascript operations are
programmed against a higher level Javascript API, minimizing
dependencies on one Javascript library. If we are going to put in this
layer, we need to closely consider the costs/benefits. The costs to
consider are flexibility, bugs introduced by layering and delegating
everything, introducing yet another programming api, and feature work
not being implemented due to time spent writing layer and delegate
code -- all against the benefits, which you should talk more about...
I mean, it would be nice if ajax implementation doesn't rely on only
one
toolkit or implementation. So others can implement their own.
I should point out that the AJAX Customizations API is callable from
any Javascript library. So you are free to implement your own client
side code from that POV
Maybe I can propone patches to leave door open to other toolkits and
make
jetspeed interface generic...
Lets discuss it more. Now that I am beginning to learn about your what
you want to do, there are a few coordination improvements we need to
make:
1. I have an in-progress issue I am actively working on. https://issues.apache.org/jira/browse/JS2-1084)
. I would like the opportunity to contribute too, with your approval
of course...
2. Your patches are going to be out of date. I am working and
committing as I go on a documented JIRA issue. If you want to work on
any part of this issue, you need to work closer with me and we can
decide who works on what so we don't have conflicts and so that we can
coordinate and collaborate on the work. I would very much like to
collaborate with you on this work, please do not misinterpret my
caution to jump on the 'layering API approach' before analyzing the
costs/benefits as something else.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
