I had no a good chance to complete read you past email, since I am sick today. Some comments inline
On Mon, Sep 29, 2008 at 4:57 PM, Andrew Robinson <[EMAIL PROTECTED]> wrote: > Update: > > Somehow I royally messed up the Jira query and re-ran it this morning. > There are 285 issues that were either improvement, wish or new feature > requests that have been made to Trinidad. > > After thinking more about this email, I should have taken a different > approach. After mulling it over some more (I had been writing the > email for a while, but for some boneheaded reason, I don't re-think > things until after I send the darned emails), I don't think that > creating a new library is a good choice at all. I was just thinking > that a new library would not solve anything and in fact probably would > lead to a less involved library anyway. > > I guess what I really wanted to know, was: > > 1) How many people are willing to work on the lingering Trinidad > issues (bugs or improvements) that have been open for many months? I am. > > 2) How can we as a community get some of the old code cleaned up? > > 3) What is holding us back on things like removing UIXNode-based renderers? nothing. actually this was already assigned to me in the past... never had time for it. I want Trinidad2 being ontop of JSF2 and that should update also give us time to do the clean up. > > 4) What do people thing is a good way to get some excitement around > Trinidad to get these old issues cleaned up? > > 5) What is the best way to tackle issues of changes to the API in > Trinidad that don't belong in the Rich Client and be able to keep both > frameworks happy? > 5a) for example, how can functionality that only belongs to Trinidad > be added to UIXComponentBase without causing problems? > > 6) Are people interested in making Trinidad's API more open (more > public, non-final methods in API classes, more hooks to be able to > customize aspects of Trinidad)? > - Possible examples: adding PPR hooks to allow renderers to do more > than just DOM element replacement on client ID, adding onComplete like > functionality to use with autoSubmit. > > I think this is really want I want to get at. For me to see no > progress for over 6 months on many issues, not see people's patches > applied, etc., is disheartening. I am part to blame and should also be > helping close some of these issues. it is all a matter of time... so why not sending more polite emails before, instead of bashing against almost everybody here from Oracle (expect you)... ? And it is really not that everybody is doing a veto against any enhancement suggestion. > > So what do you think? I will send more tomorrow, when I am better. > > -Andrew > > On Sun, Sep 28, 2008 at 4:40 PM, Andrew Robinson <[EMAIL PROTECTED]> wrote: >> After working and using Trinidad for about a year now, I have noticed >> that although there have been many releases, the project just doesn't >> seem to be progressing. I am curious what other MyFaces members think >> about this. Just by browsing JIRA, it seems that almost all the work >> is done is bug fixing, but not enhancing Trinidad. Here are some >> disturbing JIRA statistics from last week: >> >> - 331 open issues in Trinidad >> - 239 are bugs in an unresolved state, 14 with a patch available and >> 154 of which are over 6 months old >> - 14 bugs are marked as blockers or critical, 9 of which over 6 months old >> - 140 unresolved improvement, wish or new feature requests, 21 with a >> patch available and 114 of which are over 6 months old >> - Only 4 issues are in progress, only 1 with recent updates (although >> many don't both to set "in progress" so this number is probably not >> very meaningful) >> - Only 45 improvement, wish or new feature requests have ever been >> fixed over the lifetime of Trinidad (less than 25% of those filed and >> not rejected) of which only 8 committers were involved >> >> Another sign of stagnation is that Trinidad has plenty of legacy >> UIXNode code from the early Oracle ADF days, there has been no >> movement to address this and bring Trinidad fully into the JSF >> architecture. Many of the components that are still ADF based are >> major ones like the tree and the navigation tree. >> >> New features seem to be debated harshly on the dev@ mailing list, >> there is always a strong resistance, sometimes by just a few people >> and silence from much of the rest of the community that results in >> lack of adopting any improvements. No new components have been added >> to Trinidad to my knowledge since the lightweight popup control (for >> which the author is no longer active). Only one new skin has been >> included, and that was donated by Oracle (suede skin). The demo has >> not improved, nor has the documentation or website undergone any major >> improvements. >> >> I think a large part of the lack of progress, but a high involvement >> for some bugs is the contribution of Oracle in their development of >> the rich client offering. By the way, as many know on this list, but >> some may not, I am an Oracle employee, but I am "wearing my Apache >> hat" for this email, and none of what I say here is representative of >> Oracle's standpoint. To make sure this is an Apache point of view, I >> have only included public information that anyone can learn about the >> rich client. >> >> Some may be aware that ADF development did not cease after Trinidad >> was donated. From that donation ADF has become the rich client: >> >> http://www.oracle.com/technology/products/adf/adffaces/index.html >> >> Looking at the javadoc >> (http://www.oracle.com/technology/products/adf/adffaces/11/doc/multiproject/adf-richclient-api/apidocs/index.html) >> you can see that the rich client is based on Trinidad's framework and >> some of the components but none of the renderers. What this means is >> that Oracle is very involved in assisting Trinidad's framework and >> UIXComponents, but not the Core components or the renderers. This is >> truly great to have such a large Java-based company backing an open >> source project, but there are some serious draw backs as well. Since >> the Rich Client just doesn't use Trinidad, it uses Trinidad as a >> foundation, this means that any changes to UIX components or the >> framework will appear in Rich Client as well. For example, the >> RichDocument >> (http://www.oracle.com/technology/products/adf/adffaces/11/doc/multiproject/adf-richclient-api/apidocs/oracle/adf/view/rich/component/rich/RichDocument.html) >> extends Trinidad's UIXDocument. This means that adding new >> functionality, attributes or changing the API of UIXDocument also >> affects RichDocument. So if say a Trinidad user or committer wishes to >> add an attribute onto UIXDocument that would not be beneficial for >> RichDocument, most likely and with past experience, you will find >> Oracle employees on the Apache list tent to resist the improvement and >> have sometimes vetoed the idea. As a result, any changes that would be >> beneficial to Trinidad, but harmful or even not ideal in some way to >> the Rich Client will be met with strong resistance or at least >> negative feedback. >> >> Also due to the fact that the rich client does not use all of the >> components and uses none of the Trinidad renderers, there will has >> never been any significant support from Oracle to fix, improve or >> document this code. This is why, I think, that Trinidad's Jira state >> is stale when it comes to new features and why there are no new >> components. For a hypothetical example: >> >> As a Trinidad committer, I put out an idea for a new attribute or new >> component. This feature may need a change to the trinidad-api in >> something like UIXComponentBase in order to work. Oracle is not >> interested in this feature as there is a good chance that since much >> of their code is written in JavaScript, that this change may be either >> redundant or harmful to the rich design and only apply to Trinidad. As >> such, Oracle Apache members disagree the improvement as they do not >> wish to have this functionality exposed on Rich* classes. >> >> Another problem is that if functionality is added to Trinidad at the >> core foundation or at the UIX* class level that needs support by the >> renderer, then it is also pushed back against. So if I were to change >> UIXColumn and add a new attribute that the >> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.ColumnRenderer >> would take advantage of, Oracle would have to either (1) implement >> that same functionality in its column renderer or (2) try to hide the >> attribute from the developers on RichColumn. What becomes more easy is >> that the feature is prevented by negative feedback on the mailing list >> or even vetoed so that it doesn't have to be ported. >> >> Now since the rich client is heavily JavaScript based, it is very >> dangerous to that product for Trinidad to change its PPR functionality >> significantly. Therefore, large performance improvements, more >> declarative AJAX support, XHR usage changes all are very detrimental >> to the rich client. >> >> The result of all this is that Trinidad becomes bound by the rich >> client, although I do not feel that any of this was on purpose to be >> this way. If the functionality is not deemed valuable to rich client, >> there is often negative feedback on the dev@ list just do to the >> nature of Oracle trying to protect the Rich Client and make it a solid >> component offering. >> >> If you follow the incubation process at Apache, the rich client was >> approved. There has been no code drop though, and it is unsure when >> this will ever happen (Oracle has not made any public statement on the >> progress of this to my knowledge). The information on Apache is very >> old: >> http://wiki.apache.org/myfaces/RCF_Proposal >> >> This one looks newer: >> http://wiki.apache.org/incubator/RCFProposal >> >> The donate source code is here: >> https://svn.apache.org/repos/asf/incubator/rfc >> Oops 404 :) >> >> So, as someone that cares about Trinidad, and not just Rich Client >> (yes I like the Rich client a lot, it is truly a great work with a lot >> of code and a great number of terrific features and I decided to work >> for Oracle to help build it), I also want to improve Trinidad and feel >> that the Rich Client is not a replacement to Trinidad, but rather an >> alternative. Here is why I think that Rich Client will not deprecate >> Trinidad if it is open sourced: >> >> 1) Trinidad supports more browsers (if you need IE6 support, the rich >> client will not be an option) >> 2) Trinidad is much faster due to less overhead for simple pages and >> people that visit one or two pages or your site (for at least the >> javascript footprint alone) >> 3) Rich client is more geared for web-applications rather than web >> pages and Trinidad seems more suitable for web sites in comparisson >> (not that the rich client cannot be used for web pages, but I don't >> see it being adopted for that niche for its mainstream usage) >> 4) Trinidad has a smaller learning curve to extend it (not many >> JavaScript APIs to learn) >> 5) Trinidad is server-side rendered with little javascript, appealing >> to many developers that would rather avoid heavy JS usage or are >> simply looking for a lighter client side component library. >> >> Basically the goals of rich client and Trinidad are not the same, one >> seeks to be a slick, robust, heavy-weight, JS feature rich platform >> where the other seeks to be a server-side rendered set of JSF >> components that supports AJAX. >> >> So I have been thinking lately, how can Trinidad get out of the shadow >> of the rich client and improve on its own? I think the major areas to >> address this question are: >> 1) Allowing improvements to Trinidad without them being brought into >> the rich client without intent (like a choice to merge code) >> 2) Fixing and refactoring old, antiquated and sometimes "broken" >> pieces of the Trinidad API, or just making it more possible from an >> Apache commiters point of view to update Trinidad's API >> 3) Removing all legacy code including for the most part UIX code (UIX >> node renderers for the most part) >> 4) Flexible and extensible. Trinidad is open-source, it is not a >> commercial product, but it often gets treated as such (hands off the >> code attitude, if you want to extend our code, use a different >> product), but I have heard from many users that they would appreciate >> it if Trinidad were more extensible and be more open for extending or >> adapting the code. >> 5) Fine grained building blocks to improve customization to allow >> components to look and behave . Example, the table should not have >> "select all/none" links, that should be a separate component so that >> people can create a table that works the way their company would like >> it to work, not always the way that was good for Oracle companies to >> have one standard look and feel. >> >> Would be nice things, but not required by any means: >> 1) use of a common AJAX library at MyFaces >> 2) use of a common validation framework at MyFaces >> 3) use of a common filter framework at MyFaces (specifically handling >> file uploads) >> 4) make Trinidad a component set instead of a render kit (Trinidad >> does not need custom renderers for h: core components, so why is it a >> render kit?) >> 5) hooks in the APIs to improve compatibility with other component >> libraries (allow someone to write a bridge library to join two >> normally incompatible libraries, like maybe A4J/RichFaces) >> 6) Better support for the user community to give back (Trinidad hosted >> plug-ins, easier to donate and maintain components in the sandbox, >> user donated skins, etc.) >> >> I believe that it is important to try to preserve Oracle's support of >> Trinidad at the bug fixing level, but allow Trinidad to live a >> separate life from the rich client so that it can grow. By creating a >> separation of Trinidad and the rich client, Trinidad could live a life >> of its own, becoming more open-source developer friendly and not >> having it be constrained to having only new functionality that is >> written for the rich client. >> >> A couple of options to address this that have come to my mind, are to >> either create a new branch for Trinidad (like 1.5.x or 2.x) that the >> rich client would not adopt, or spin off Trinidad into a new MyFaces >> project. >> >> In terms of a new project, the specifics could vary, but no matter how >> it was done, it would live as a library under MyFaces like Tobago and >> Tomahawk and would use pieces of Trinidad code to start with. This >> approach would give us a clean slate to start with and also plenty of >> experience and code to leverage from the existing source. APIs could >> be enhanced and cleaned up, removing any legacy methods or aproaches, >> and the UIXNode architecture would be easily removed. >> >> Such a port, being a lot of work, could have several advantages >> though. It would allow us to add more fine grained methods, more >> declarative base attributes, more flexible components. Since it has >> been proven that no one has the desire to clean up the old Trinidad >> code, this would be a way to get developers excited. Instead of just >> cleaning up code, it would be re-writing it with much less of a >> learning curve. Besides, new code is always something that inspires >> open source developers as opposed to maintaining someone else's code. >> >> Since it would be based on Trinidad (taken from, not using), it would >> still meet the same goals and therefore still have a home in MyFaces. >> With a new project, we could try to design it so that it would work >> with other MyFaces projects better (like Tomahawk). Having a new >> project would also allow developers who like Trinidad to be able to >> add new robust features and make new components and make other changes >> without the problem of Oracle trying to stop it from affecting the >> rich client. >> >> In such a new project we could even enhance the sandbox to not just >> components, but sub-projects. For example, there could be jQuery, YUI, >> Dojo based Trinidad components shipped as separate jars for those that >> want a little more JavaScript integration and want to not re-invent >> the wheel (there are so many JS libraries out there that would work >> fine in a JSF environment that no one has really embraced to help >> users do this). >> >> In summary, I love both Trinidad and the rich client, but I really >> feel that something needs to be done to help Trinidad out of its >> apparent stagnation. The Trinidad community has too restrictive to new >> features and too slow on Trinidad updates from what I have seen. The >> components with their renderers have not improved in a very long time >> (practically since the donation). >> >> This is not a vote, this is just a discussion I wanted to spark. To >> help find out what people think, here are some ideas on a quick >> response: >> >> 1) I like the idea of a new library based on JSF 1.2 and taken from >> Trinidad as a starting point >> 2) I like the idea of a new library, and I think it would be great to >> start it as a JSF2 only set of components >> 3) I like the idea of two separate Trinidad branches, not creating a new >> library >> 4) I think something should be done, not sure what, but I really don't >> want another component library offered at MyFaces >> 5) I'm indifferent >> 6) I like things the way they are and do not want change with respect >> to Trinidad >> 7) Other: (enter here) >> >> Thanks for reading this through. >> >> -Andrew >> >> PS, my preference is #1 in the list above. >> > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
