portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gonzalo Aguilar Delgado <gagui...@aguilardelgado.com>
Subject Re: Other toolkits
Date Fri, 27 Nov 2009 18:49:22 GMT
Hi David, 

> 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.

Yes. I know that point and that's true. It's better to be cautious. This
is why I will go slow
with this point. Apache is a meritocracy so I have to slowly grow up as
a apache developer.

No prob. I have lot's of things to do and it's not my first objective
also. But don't want to 
close doors...

> > 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 found that it should be not much work for now. I think current work
done with the new ui
is well established and can be used with other toolkits... Don't waste
too much time on this
but just think about it. 

Also, maybe there are other ways to do it... Don't know.

> 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 mix things but what I'm talking about is about replacing
clientside code with anything else.

> 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:

Sure... Let's take time and do it well...

> 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...

I will finish some things I have pending with Woonsan and the will go
with this...

> 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.

Let me take a look closer on how things works, then we can take time to
plan... If it has
any benefits... 

Thank you for considering...

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message