incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Peller <>
Subject Re: AJAX Toolkit Framework Proposal
Date Wed, 21 Dec 2005 05:25:08 GMT
I think it's been mentioned a couple of times, so I'll try to clarify what
Zimbra is about.  Zimbra is primarily a client-side AJAX toolkit.  There is
a small server-side component, currently implemented as JSPs (though we've
hacked up a PHP-based version as well as proof of concept)  The server
piece is simply to assemble the page and do some handling of string bundles
and locales for internationalization.  If we can find ways to do this on
the client, we should do so.  There is also a build-time piece to assemble
images into groups and separate into high-res and low-res versions for
optimal image handling.  Otherwise, the functionality is bound to the
client-side DOM with JavaScript, as you'd expect.

Zimbra does have a Java feel to it; it will be familiar to Java programmers
and SWT programmers in particular.  You might view that as a strength or a
weakness.  It's just one approach.  Old school JavaScript?  Well, it may
not have namespaces, but it is object-oriented.  Your criticisms are well
noted, and this again is what we would like to get out of the incubation
process.  If namespaces would be helpful to Zimbra, perhaps it's not too
late to add them?  Same for other progresssive programming techniques that
could be incorporated.

Download size and speed are concerns.  There are many ways to address this,
including tooling that is on our todo list for generic handling of
whitespace, compression of symbols, coalescing into fewer files, etc (does
not necessarily have to be Eclipse-based, btw) and handling of dependencies
could also help bring down the download size, not just for Zimbra but for
other JS code as well.  There is plenty of room for improvement, and we'd
like to work on all these things under the guidance of and with assistance
of the Apache community.

Regarding the coupling between the toolkit and the runtimes, I can only say
that there is no secret handshake and that we are currently implementing
plugins for three different runtimes to prove our point.  Zimbra was the
first.  Now each runtime is different, and we are trying to find
commonality where we can.  With each new runtime we may discover new
requirements on our public APIs, etc., but the goal is to have pluggable
runtimes and to be "friendly" to as many toolkits as possible.  To get
custom functionality, some runtimes will clearly have a lot of code to
write. It's not all going to be wizard driven.

I tried to provide a more complete explanation of our dependencies on
xulrunner and javaconnect in my reply to Sanjiva tonight -- let me know if
it needs clarification.  Rico is present only so that the tooling may
deploy it with Rico-based projects (unmodified).  JSLint and Rhino are both
used for syntax checking in the IDE (both on-the-fly and in batch mode) and
are packaged within Eclipse plugins as binaries, unmodified.

And lastly, tooling and runtimes do not have to be the only subprojects.  I
hope I mentioned it in the proposal, but there are other ideas kicking
around for AJAX utilities as well, such as a shared client-side data model,
which might be implemented in such a way that it could be used by more than
one runtime.


             Martin Cooper                                                 
             rg>                                                        To 
             Sent by:                
             mfncooper@gmail.c                                          cc 
                                       Re: AJAX Toolkit Framework Proposal 
             12/20/2005 07:49                                              
             Please respond to                                             

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
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
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,
is popular but fragile, and will rapidly lead to problems in any
environment, especially in portals.

4) While #3 above is technical in nature, such a code base coming to the
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
be trying to lead the way in the new world of AJAX. This, of course,
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
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

Martin Cooper

On 12/20/05, Sam Ruby <> 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 <> 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 <> wrote:
> >>
> >>>AJAX Toolkit Framework Proposal
> >>>
> >>>0.  Rationale
> >>>
> >>>While the term AJAX (Asynchronous Javascript and XML) has only
> >>>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,
> 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
> >>>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
> >>>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
> >>>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
> >>>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
> >>>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
> >>>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
> >>>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:
> >>>
> >>>
> >>>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
> >>>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
> >>>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
> 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
> 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
> >>> and
> >>>
> >>>
> >>>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
> >>>  A snapshot of the AJAX
> >>>toolkit code is provided at
> >>>
> >>>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]
> >>>
> >>>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.
> >>>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:
> >>>For additional commands, e-mail:
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail:
> >>For additional commands, e-mail:
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message