incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
Subject Re: AJAX Toolkit Framework Proposal
Date Wed, 21 Dec 2005 00:49:29 GMT
Some comments:

1) This appears to be two proposals rolled into one. One is to incubate a
JavaScript toolkit. (It's not clear to me at this point whether or not that
toolkit includes a server-side component, but that's not really relevant at
this point.) The other is to incubate a development environment that can be
used with that toolkit, or apparently with other toolkits if the necessary
work is done. The former comes from Zimbra; the latter from IBM. It's not
clear to me why this is a single proposal and not two separate ones. I
understand that there is synergy between the two, but I believe that
explicitly separating them will make each part stronger. The proposal as it
is now leaves quite a bit if doubt as to where one ends and the other
begins, begging the question of just how separate they really are, and how
"friendly" to other JavaScript toolkits.

2) Various comments have been made regarding multiple ASF projects
addressing the same area being OK, and indeed a good thing. While I
generally agree with that sentiment, there are grounds for concern when it
comes to JavaScript toolkits running in the browser. One issue is that of
footprint. As it is today, Zimbra appears to be about a 1.25MB download to
the browser, if everything is included. That is *massive* for a JavaScript
toolkit. To include that for, for example, one portlet on a portal page,
while the remaining portlets use other toolkits, and hence yet more
downloads, is expensive and slow. This may sound theoretical, but recall
that another substantial JavaScript toolkit is already on its way to the
ASF, in the form of ADF Faces from Oracle, heading for MyFaces. That project
is not (I sincerely hope) going to want to develop components that target
multiple huge JavaScript toolkits in the same library.

3) Related to the above, but from a more technical perspective, it is very
disappointing to see so much old-school JavaScript in this toolkit. For
example, the code is not namespaced, leading to greater potential for
collisions, and appears to be written more like Java code, instead of taking
advantage of the features of the JavaScript language. (This is likely a
factor in why the amount of code is so large.) The use of the Rico toolkit
is also mentioned in the proposal. That toolkit is built on Prototype, which
is popular but fragile, and will rapidly lead to problems in any non-uniform
environment, especially in portals.

4) While #3 above is technical in nature, such a code base coming to the ASF
will tend to lend credence to the way it is structured and built, as a
side-effect of the stature of the ASF. IMO, it would do the JavaScript
community a disservice to promote old-style JavaScript coding when we should
be trying to lead the way in the new world of AJAX. This, of course, doesn't
apply to the IDE part of the proposal, which I'm sure any JavaScript
developer would appreciate (as long as it works with their toolkit of
choice, which it purports to do ;).

5) Given that we have numerous open issues regarding the inclusion of
components with non-Apache licenses, I would like to see a more explicit
description of the relationship between the proposed code base and other
artifacts mentioned in the proposal, such as XULRunner, JavaConnect, Rhino,
JSLint and Rico. I know that we current have a problem with Rhino because of
the NPL. What other issues does this proposal introduce?

Personally, I am less than happy at seeing yet another large project
proposed from a corporate source (and IBM at that), along with a dozen new
committers who have not earned their merit at the ASF as most committers
have. I feel the ASF is losing its way, and becoming a repository for
corporate open-sourcing along with taking on responsibility for building
communities around corporate code bases. I suspect I'm in the minority at
the ASF, and I'm undoubtedly in the minority here in the incubator. But
there doesn't seem to be a way for the incubator to say "no thanks", other
than by a podling failing the incubation process, and that seems wrong to
me.

--
Martin Cooper


On 12/20/05, Sam Ruby <rubys@apache.org> wrote:
>
> Kenneth Tam wrote:
> > I have a more specific question: have you guys considered separating
> > this into a plug-ins/tooling donation to Eclipse, and a runtime
> > donation to Apache?  It seems like the IP is already in a form that
> > makes this easy (ie, the AJAX Toolkit Framework Eclipse plugins from
> > IBM, and the AjaxTK Javascript library from Zimbra), and there are
> > several examples that suggest this kind of parallel community building
> > works well.
>
> I'll take this question, as well as Cliff's below.
>
> First, for starters, it is worth noting that there is Apache Licensed
> code all over the internet - SourceForge, CodeHaus, people's private
> sites, whatever.  Similarly for Eclipse plugins.
>
> Second, code licensed under the Apache license can be sublicensed and/or
> bundled/shipped with other projects.  Example: Eclipse ships Ant.
>
> Separate from the IP, the goal is to build a community, a single place
> to go to where AJAX related components can be found.  We see an
> opportunity to build such a community independent of where the
> components originated.  A community where Dojo and others would be
> welcome (but not required!) to join, or not, as they wish.
>
> Adam can certainly speak to the technical aspects of this than I can,
> but AJAX certainly causes one to rethink the traditional client/server
> boundary, in fact it tends to blur it.  One can pick off small pieces
> and say this definately belongs on the server, and that could ship with
> eclipse, but there are also gray area pieces that we could pick a spot
> based on our current understanding, but over time or with the inclusion
> of new members and their points of view, our understanding may shift.
> It would be advantageous if everything were licensened identically so
> that such decisions could be made on a purely technical basis, and not
> based on other considerations.
>
> Life is hard enough as is.
>
>   - - -
>
> Could we develop this at the ASF with the Eclipse license?  The answer
> would be no.  Could we develop this at Eclipse with the Apache
> license... I'll let Eclipse answer that.
>
> Could we develop this at the ASF, with the Apache license, and let
> Eclipse sublicense and/or bundle and ship any or all of this?  That
> question I can answer: yes!  And the hope would be that this could serve
> as the basis for some cross fertilization and teamwork between the two
> larger organizations.
>
>   - - -
>
> Now to directly Cliff's question: yes, we considered proposing this to
> Eclipse.  And we talked with a number of people there.  And surprisingly
> enough - we thought those discussions were settled but they seem to have
> sprung back up again after Adam sent in the proposal.
>
> We will pursue those discussions to their completion.
>
> Suffice it to say that Eclipse folks are following this mailing list.  I
> invite them to share their thoughts here.
>
>   - - -
>
> My recommendation is that we focus on concrete proposals, and code
> bases.  If people would like to suggest specific additions or removals
> from the proposal, lets hear it.  The proposal as it stands is to build
> a unified, vibrant, and diverse community around code licensed under the
> Apache License, version 2.0.  And here seems like a good place to make
> that happen.
>
> - Sam Ruby
>
> P.S.  If this isn't complicated enough, there is a third party: Mozilla
> involved.  At least there the line seems somewhat clearer.
>
> > On 12/20/05, Cliff Schmidt <cliffschmidt@gmail.com> wrote:
> >
> >>Adam,
> >>
> >>Can you tell me if you considered proposing this to the Eclipse
> Foundation?
> >>
> >>Since this project appears to have far stronger dependencies on
> >>Eclipse Foundation projects rather than anything from Apache, can you
> >>tell me why you think bringing this project here is likely to help you
> >>build a stronger community than you would find at Eclipse?  Is there
> >>some other overriding reason you prefer to bring this project to
> >>Apache?
> >>
> >>Cliff
> >>
> >>
> >>On 12/20/05, Adam Peller <apeller@us.ibm.com> wrote:
> >>
> >>>AJAX Toolkit Framework Proposal
> >>>
> >>>0.  Rationale
> >>>
> >>>While the term AJAX (Asynchronous Javascript and XML) has only recently
> >>>been coined, the underlying web standards and technologies (JavaScript
> >>>a.k.a. ECMAScript, DOM, XML, SOAP, and so on) have been around for
> years.
> >>>Although the term is used in a variety of ways, AJAX typically
> describes
> >>>techniques towards developing interactive applications on the web
> client
> >>>including asynchronous messaging, use of XML grammar in client-side
> >>>applications, incremental page updates, and improved user interface
> >>>controls. AJAX applications combine the rich UI experience of
> programmed
> >>>clients with the low-cost lifecycle management of web-based
> applications.
> >>>
> >>>AJAX has raised awareness of the high potential of web applications, it
> has
> >>>encouraged companies to adopt rich web-based interfaces over
> traditional
> >>>"fat" clients, and it has spawned development activity to create
> toolkits
> >>>and abstractions to make AJAX-style development easier and more
> powerful.
> >>>This is an important trend for open source.  The client itself can be
> >>>composed entirely of open-source parts, such as Mozilla's Firefox or
> KDE's
> >>>Konqueror, and does not require any particular operating system,
> helping to
> >>>make a more level playing field for all development.  More importantly,
> >>>AJAX is back-end agnostic as transactions are done over HTTP.  Keeping
> the
> >>>client open forces vendors to keep the communication channel open as
> well,
> >>>and this can only continue as long as the client technology keeps pace
> with
> >>>proprietary alternatives.  The open, standards based communications
> channel
> >>>is what drives many technologies inside Apache, so success of the open
> >>>client is vital to Apache.  The mission of this project is to encourage
> >>>innovation around enterprise-strength client runtimes and tools and
> build a
> >>>community which can select and nurture a select set which will be most
> >>>beneficial to the web.
> >>>
> >>>0.1 Criteria
> >>>
> >>>Meritocracy:
> >>>
> >>>Apache was chosen for an incubator primarily because of the guidance
> the
> >>>community can provide.  The two subprojects put forth are among the
> first
> >>>attempts to formalize this style of development.  Additional ideas,
> tools
> >>>or entire runtimes may come forward and indeed would be welcomed to the
> >>>project, either wholesale as new subprojects or incorporated into the
> >>>existing code.
> >>>
> >>>Community:
> >>>
> >>>The contributed work was inspired by open source development but needs
> a
> >>>strong and diverse community to validate its mission and carry it
> forward.
> >>>A primary objective of the project is to build a vibrant community of
> users
> >>>and active contributors.
> >>>
> >>>Core Developers:
> >>>
> >>>All of the initial committers are members of Zimbra and IBM development
> >>>teams.  All developers have worked on open source projects before and
> have
> >>>experience and understanding of open source principles.
> >>>
> >>>Alignment:
> >>>
> >>>Initial implementation consists of two sub projects.
> >>>
> >>>The AJAX Toolkit Framework will provide a strategic framework for
> >>>Interactive Development Environments (IDEs) for the many different AJAX
> >>>toolkit offerings in the market. It provides a rich set of tools for
> the
> >>>AJAX / DHTML developer including: a JavaScript editor with edit-time
> syntax
> >>>checking; Mozilla web browser; integrated DOM browser; integrated
> >>>JavaScript debugger; and wizards and development aides tuned to
> specific
> >>>libraries and toolkits.  The Framework is extensible to support other
> AJAX
> >>>toolkits and has a wizard-based tool to facilitate the integration of
> new
> >>>toolkits in the framework.
> >>>
> >>>The AJAX Toolkit Framework has dependencies on  Mozilla XULRunner and
> >>>JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a
> set of
> >>>Plugin extensions to Eclipse. It embeds 4 other open source components:
> >>>Rhino, JSLint, Rico and Zimbra.  No code modifications will be made to
> the
> >>>4 open source components specified. They are incorporated to
> accommodate
> >>>Eclipse plugin architecture and distributed as-is by repackaging them
> as
> >>>part of the AJAX Toolkit Framework.
> >>>
> >>>The Zimbra AJAX Development Toolkit, the first toolkit integrated into
> the
> >>>framework, provides a rich client library, similar in style to
> traditional
> >>>object-oriented widget libraries like Eclipse's SWT.  This toolkit
> hides
> >>>implementation details and browser quirks and makes web development
> more
> >>>accessible to the enterprise developer.  It provides
> >>>
> >>> * User interface development
> >>> * Network communications (both synchronous and asynchronous)
> >>> * SOAP programming
> >>> * XML document creation and manipulation
> >>> * UI event handling and management
> >>>
> >>>For further information, please see the Zimbra AjaxTK whitepaper:
> >>>http://www.zimbra.com/pdf/Zimbra%20AJAX%20TK%20Whitepaper.pdf
> >>>
> >>>0.2  Warning signs
> >>>
> >>>Orphaned products:
> >>>
> >>>The initial code submission is based on colloborative work between IBM
> and
> >>>Zimbra to provide a toolkit and a framework to embed the toolkit in IDE
> >>>environment and provide additional enhancements. Both the companies
> believe
> >>>that taking a joint approach and making it available through open
> source
> >>>will make it widely accepted and create a community and unify Industry
> >>>momentum to consolidate requirements and accelerate community growth
> and
> >>>enhance the toolkit to ease development of AJAX applications.
> >>>
> >>>Inexperience with open source:
> >>>
> >>>Both the companies and several of the commiters are very experienced in
> >>>Open Source environment. All efforts will be made to ensure that the
> work
> >>>done and momentum will be in strict adherence to open source
> guidelines.
> >>>
> >>>Homogenous developers:
> >>>
> >>>The current list of committers includes developers who are
> geographically
> >>>distributed.  They are experienced with working in a distributed
> >>>environment, and with resolving technical differences.
> >>>
> >>>Reliance on salaried developers:
> >>>
> >>>All of the initial developers are paid by their employers to contribute
> to
> >>>this project and the employers track records for ongoing investment in
> open
> >>>source communities well known.
> >>>
> >>>No ties to other Apache products:
> >>>
> >>>The initial codebase will be licensed under the Apache License 2.0.The
> >>>dependencies on other external projects are defined in the alignment
> >>>section.  While there are no direct build dependencies on other Apache
> >>>projects, the development of AJAX clients will often be driven by
> Apache
> >>>middleware and will have a positive impact on the open source movement
> as
> >>>described in the "Rationale" section.
> >>>
> >>>A fascination with the Apache brand:
> >>>
> >>>The committers are intent on developing a strong open source community.
> We
> >>>believe that the Apache Software Foundation's emphasis on community
> >>>development makes it the most suitable choice.
> >>>
> >>>1. Scope of the subprojects
> >>>
> >>>
> >>>The subprojects will include development tools necessary to encourage
> >>>browser-based, AJAX-style development for individual users as well as
> in
> >>>the enterprise.  The tools will be driven by an extensible IDE
> Framework
> >>>and may include utilities to assist in code development, analysis, and
> >>>testing.  The tools will be adaptable to different AJAX runtimes, some
> of
> >>>which will also be subprojects in the incubator.  The initial
> submission
> >>>includes an IDE and one such runtime.
> >>>
> >>>These initial projects are intended merely as starting points and
> should
> >>>not be taken as bounding the scope of the project as a whole. Some
> other
> >>>potential projects may include:
> >>>
> >>> * WYSIWYG tools for building AJAX-style interfaces
> >>> * Declarative grammars or abstractions for AJAX programming
> >>> * A common data model to facilitate efficient server communication
> with
> >>>Javascript or DOM access
> >>>
> >>>2. Identify the initial source from which the subprojects are to be
> >>>populated
> >>>
> >>>AJAX Toolkit Framework was developed at IBM as a set of plugins based
> on
> >>>the Eclipse Framework and WebTools Project.  Zip files containing
> snapshots
> >>>of CVS directories are provided with this proposal at
> >>>http://www.apache.org/~rubys/ajax/ajaxtk-framework-ibm.tgz and
> >>>http://www.apache.org/~rubys/ajax/ajaxtk-framework-contrib.tgz
> >>>
> >>>The Zimbra AjaxTK is available today in open source, and can be
> downloaded
> >>>as part of the Zimbra Collaboration Suite (choose the source code
> version)
> >>>at
> >>>http://www.zimbra.com/community/downloads.php.  A snapshot of the AJAX
> >>>toolkit code is provided at
> http://www.apache.org/~rubys/ajax/Ajax.tar.gz
> >>>
> >>>2.1 External Dependencies of the project
> >>>
> >>>AJAX Toolkit Framework has dependencies on Mozilla XULRunner and
> >>>JavaConnect, and Eclipse WTP. AJAX Toolkit Framework is written as a
> set of
> >>>Plugin extensions to Eclipse. It embeds four other open source
> components
> >>>Rhino, JSLint, Rico and Zimbra.  No code modifications will be made to
> the
> >>>four open source components specified. They are incorporated to
> accommodate
> >>>Eclipse plugin architecture and distributed as is by repackaging them
> as
> >>>part of AJAX Toolkit Framework. In the future any AJAX toolkit that is
> to
> >>>be supported can be included as another plugin.
> >>>
> >>>3. Identify the ASF resources to be created
> >>>
> >>>3.1 mailing list(s)
> >>>
> >>>    * ajaxtk-ppmc
> >>>    * ajaxtk-dev
> >>>    * ajaxtk-commits
> >>>    * ajaxtk-user
> >>>
> >>>3.2 Subversion repository
> >>>
> >>>    * [WWW] https://svn.apache.org/repos/asf/incubator/ajaxtk
> >>>
> >>>3.3 Bugzilla
> >>>
> >>>    * AJAXTK (AJAXTK)
> >>>
> >>>4. Identify the initial set of committers:
> >>>
> >>>    * Craig Becker
> >>>    * Leugim Bustelo
> >>>    * Andrew Clark
> >>>    * Conrad Damon
> >>>    * Ross Dargahi
> >>>    * Becky Gibson
> >>>    * Javier Pedemonte
> >>>    * Adam Peller
> >>>    * Roland Schemers
> >>>    * Donald Sedota
> >>>    * Parag Shah
> >>>    * Greg Solovyev
> >>>
> >>>5. Identify Apache sponsoring individual
> >>>
> >>>We request that the Apache Incubator PMC sponsor the AJAX Toolkit
> Framework
> >>>as an
> >>>incubating project, with the eventual goal of graduation as a TLP.  The
> >>>initial contributors feel the scope of the project doesn't clearly
> >>>overlap with any existing TLP, and is broad enough to justify eventual
> >>>TLP status.
> >>>
> >>>Champion:    Sam Ruby
> >>>
> >>>Mentors:     ??
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>>For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

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