AJAX Toolkit Framework Proposal

[JAMES Nightly Build System]

Mike Milinkovich wrote:

> So your assertion is that all open source code should be
> done at Apache and there are no reasonable scenarios in
> which another open source community can or should attempt
> to co-operate with Apache?

I don't believe that Sam said anything of the sort.

> Solomon has decided many times in the past.

Just because it irks me to see references abused, I'd like to remind
everyone that Solomon's suggestion was a trick, and that Solomon awarded the
child to the woman (the real mother) who would rather give it up than see it
killed.  That isn't to say anything about the merits of the on-going
discussion.  Just wanted to put the reference back into its proper context.

        --- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[dims]

Mike,

Some one comes to ASF with a proposal, typically we give it our full
consideration. I can understand why cliff asked about eclipse option
(Beehive/Eclipse stuff!), but i can understand Adam/Sam's view
completely as I am on the "ASL 2.0 is good" band-wagon and i do want
ASF's stamp on everything i do. I really don't mind if Apache gets
into Eclipse tools/plugins. We do have Eclipse plugins in Axis2
project. We also have another plugin for running Geronimo inside WTP.
So it's not a new thing and the proposal has my +1.

Please pardon me for being blunt, I don't really care about what
happens inside IBM/Eclipse or who said what/when. All i know is that
we have a proposal in front of us and as a community we take it or
leave it or ask for changes if we think they are needed. As far as i
can see "since we did it before, we should do so again" is not a
strong argument for requesting a change to the proposal. FWIW, i've
been on the receiving end of unpleasant surpises as well. Take
ServiceMix/Geronimo for example. It's a fact of life here and we all
have learned to deal with it :)

Thanks,
dims

On 12/20/05, Mike Milinkovich <mike.milinkovich@...> wrote:

>
> > In particular, why would taking Solomon's advice and dividing
> > the child in half be benefitial (sic) to anybody?
>
> Interesting question. So your assertion is that all open source code should
> be done at Apache and there are no reasonable scenarios in which another
> open source community can or should attempt to co-operate with Apache?
>
> I would point out that the "runtime at Apache and tools at Eclipse" is not a
> new scenario. It has been repeated numerous times with great success for
> both our communities and their mutual consumers.
>
> Solomon has decided many times in the past. With a strikingly different
> conclusion than what you are proposing here.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
>

--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Adam Peller-5]

Hey Sanjiva!  Yeah, it's been a while.  I've been trying to follow your
projects and blogs over the years.  Sounds like all is going well.

No secret agendas here :)  Happy to answer.

>So this may not be an appropriate part of the discussion for deciding
>whether to accept this for incubation or not but I'm concerned about
>complexity. A key reason for the evolution of AJAX is that the "old way"
>was too damned complicated. This proposal appears to be offering a
>framework to layer over frameworks! Is that correct? If so why do you
>believe that anyone other than the Zimbra toolkit (which is part of this
>proposal) will in fact come and port their framework to this world.

For starters, I have to apologize for the names.  "Toolkits" and
"Frameworks" are likely to be misinterpreted, and yes, it almost sounds
circular.  Hopefully we can come up with a better name for the tooling
subproject, but any time we come up with something, it gets shot down
internally as an existing trademark.  We're open to suggestions :)

There's really no meta-framework here, per se, and nothing to port.  Here's
what we're trying to do:

1) The tooling subproject consists of some generic DHTML/AJAX tooling that
ought to be applicable to just about anyone.  We then provide plugins (you
might think of them as adapters) to support various runtimes, like Zimbra.
(The submission has implementations for Zimbra and Rico, and we're working
on support for Dojo as well)  The plugins start out by handling the
mechanics of creating projects, structuring directories, deploying projects
and the like.  We all know how painful these things can be to do manually.
In addition to this, there are wizards to guide you through code creation,
snippets and templates for repetitive tasks, etc.   Typically this does not
require any change to the runtimes, though in the case of Zimbra we did
shuffle the directory structure around a bit.  The tooling "framework" is
extensible so that support for other runtimes can be added.  We even
provide tooling to create the tooling.  This starts with a boilerplate
process, driven by a wizard, which asks for things like the location of the
libraries, naming patterns and templates for empty pages, etc.  The result
is a set of plugins which act as adapters to the new runtime.  I hope that
runtime authors would jump at the chance to write adapters so that their
users could enjoy the benefits of IDE integration.

2) The other subproject is Zimbra itself, but there may be other runtimes
here as well.  As you say, the main goal here is to provide layers of
abstraction to hide the traditional browser tricks and quirk modes to make
browser-based programming more productive, and Zimbra does this well.

>Also, is the proposed framework intended as a client side platform? That
>is, is it basically an alternative to using a browser on the client side
>as a host for AJAX applications? Or is it just some kind of tooling
>framework?

Just a tooling framework.  The browser is always the intended client.

>I've looked at the Zimbra SOAP stuff (very) briefly and its pretty
>primitive. Do you expect to continue to develop that into a fully
>fledged SOAP infrastructure (supporting addressing, security, RM and all
>that WS -* stuff) or depend on someone else?

Yes, the SOAP layer in Zimbra is pretty basic, though I don't know of many
web-based clients that have gone further. I think the intent is to expand
on it.  Though given that we are targeting the browser and not some
alternate platform, there are probably going to be limits on what we can do
and what makes sense.  Do you think a full-fledged SOAP model would be
useful from a web client?  Much of the time, as you say, the simple
XML/JSON/REST model works well enough for the client, especially when you
have restrictions like the browser's same domain policy.  The
infrastructure for security doesn't seem to be there on the client, and I'm
not sure anyone really wants it there?  Similarly, it's hard to imagine
implementing everything required to support attachments and encryption from
JavaScript, but I guess anything is possible?  Perhaps proxying messages
with JSON/REST and doing SOAP on the backend, pushing issues like security
and state to the server is the way to go?  I think it might be best to
leave this as an open question.  I think this is exactly the sort of thing
we'd like to learn from the incubator -- which AJAX messaging models make
sense, and where do we focus our development efforts?

Regarding Mozilla:

>Are they contributing code and/or committers too?

No, Mozilla is not a contributor or committer here, at least not now.

>Or did you mean in the
>sense that the proposed project depends on XUL and its runtime? (Is that
>a Java thing BTW or is there a plan to do some JNI bridge to it from
>Eclipse WTP?)

Funny you should ask...  Yes, there is a dependency on xulrunner, but there
is also a Mozilla XPCOM to Java bridge (javaconnect) which was developed by
at IBM by Javier Pedemonte and was contributed back to mozilla.org.  Part
of it is in our posting as a 3rd party contribution but will eventually it
will all be hosted at mozilla.org -- note that besides Mozilla being a
logical home for this code functionally, there are actually very tight
build dependencies, unlike the Eclipse work.  This is an enabling layer for
our tooling but it has many other uses.

We've used javaconnect to implement our debugger and DOM inspector which
write to the same native XPCOM APIs as their JavaScript counterparts
Venkman and the Mozilla DOM Inspector, but instead have Eclipse integration
points.  This tight integration with Mozilla can enable some powerful
tooling, maybe even some test automation?  Lots of possibilities.  And
while we're doing all this tight integration with Mozilla, I should point
out that it is only to enable tooling and should not impact the runtimes.
We of course do NOT advocate writing code to any one browser.

Regards,
Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Mike Milinkovich]

> > So your assertion is that all open source code should be done at
> > Apache and there are no reasonable scenarios in which another open
> > source community can or should attempt to co-operate with Apache?
>
> I don't believe that Sam said anything of the sort.

Really? I am truly not meaning to be argumentative. Can you tell me what
your interpretation of the Solomon reference would be, given the numerous
precedents of mutual co-operation that predate this proposal?


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Mike Milinkovich]

> Please pardon me for being blunt, I don't really care about
> what happens inside IBM/Eclipse or who said what/when.

Dims,

Trust me, no one hates that bullshit more than I. I was just reacting to
Sam's assertion that Eclipse was fully informed and happy with outcome and
wanted to be precise in my response.

At the risk of pointing out the obvious, Eclipse is no longer part of IBM,
and has not been for almost two years. We've been an independent Foundation
since Jan. '04. So "...inside IBM/Eclipse..." does not happen any more than
"...inside IBM/Apache...".

I realize this is unrelated to the topic at hand, but just wanted to clear
up any confusion.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Adam Peller-5]

Cliff,

Sam has gone through the rationale on community, licensing, etc.  On a technical level, I'd like to point out that while the tools subproject does use
 Eclipse and the WebTools project, it attempts to do so through limited, well-known APIs.  We've been working with the Eclipse team on defects and
enhancements to find the right APIs not just for our needs, but hopefully generic APIs for others to build extensions as well.  Once these APIs and
extension points are finalized, hopefully Eclipse will be a stronger platform as a result, and we will be freer to focus on the functionality of AJAX
runtimes, integration with middleware, etc.  So, while tools are an enabler and Eclipse is the platform for the tools subproject, I think the overall
mission is building a coherent set of AJAX code that fits in with existing middleware and standards, and a community to steer it.  For that, we think
Apache is the right home.

-Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[JAMES Nightly Build System]

Mike Milinkovich wrote:

> > > So your assertion is that all open source code should be done at
> > > Apache and there are no reasonable scenarios in which another open
> > > source community can or should attempt to co-operate with Apache?

> > I don't believe that Sam said anything of the sort.

> Can you tell me what your interpretation of the Solomon reference would
> be, given the numerous precedents of mutual co-operation that predate
> this proposal?

It is one thing to question the wisdom of splitting a project, if one
perceives it that way, from going so far as to say that "all open source
code should be done at Apache and there are no reasonable scenarios in which
another open source community can or should attempt to co-operate with
Apache."  As I see it, you started from a specific example, provided an
extreme generalization, and questioned the extreme.  I would question that
extreme, too!  :-)

See: http://en.wikipedia.org/wiki/Reductio_ad_absurdum

Personally, my view has been that if a community wants to come to the ASF,
to Eclipse, or to any other place, they should be able to do so, assuming
that the organization they wish to join is willing.  And I always encourage
collaboration, and convergence where appropriate.

        --- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[geirm]

On Dec 20, 2005, at 10:32 PM, Mike Milinkovich wrote:
>
> It's rather like saying what the heck is the Apache web server  
> doing with a
> JVM project?

I say that about once a week these days ;)

geir

--
Geir Magnusson Jr                                  [phone]
geirm@...



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[dims]

Got it! thanks

-- dims

On 12/20/05, Mike Milinkovich <mike.milinkovich@...> wrote:

>
>
>
> > Please pardon me for being blunt, I don't really care about
> > what happens inside IBM/Eclipse or who said what/when.
>
> Dims,
>
> Trust me, no one hates that bullshit more than I. I was just reacting to
> Sam's assertion that Eclipse was fully informed and happy with outcome and
> wanted to be precise in my response.
>
> At the risk of pointing out the obvious, Eclipse is no longer part of IBM,
> and has not been for almost two years. We've been an independent Foundation
> since Jan. '04. So "...inside IBM/Eclipse..." does not happen any more than
> "...inside IBM/Apache...".
>
> I realize this is unrelated to the topic at hand, but just wanted to clear
> up any confusion.
>
>

--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Adam Peller-5]

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.

-Adam




                                                                           
             Martin Cooper                                                
             <martinc@...                                            
             rg>                                                        To
             Sent by:                  general@...        
             mfncooper@...                                          cc
             om                                                            
                                                                   Subject
                                       Re: AJAX Toolkit Framework Proposal
             12/20/2005 07:49                                              
             PM                                                            
                                                                           
                                                                           
             Please respond to                                            
                  general                                                  
                                                                           
                                                                           




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@...> 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@...> 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@...> 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@...
> >>>For additional commands, e-mail: general-help@...
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: general-unsubscribe@...
> >>For additional commands, e-mail: general-help@...
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@...
> > For additional commands, e-mail: general-help@...
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Cliff Schmidt]

On 12/20/05, Davanum Srinivas <davanum@...> wrote:
> Mike,
>
> Some one comes to ASF with a proposal, typically we give it our full
> consideration. I can understand why cliff asked about eclipse option
> (Beehive/Eclipse stuff!),

Actually, I had two purposes behind my question.  One was to learn
more about why the people behind the proposal wanted to come to
Apache.  Although it is nice to hear from Sam, as the project
champion, I was addressing Adam because I thought it would be nice to
hear from someone listed as a project committer as to why they thought
Apache community was a better fit.

My second reason for asking was as a polite gesture towards the
Eclipse Foundation, being another respectable, non-profit, open source
organization.  I strongly believe that the ASF is not an island in the
world of open source, and that it is good for us and all participants
in open source if we do what we can to minimize communication problems
about projects that others may have an interest in.  I probably don't
need to say any more about the relevancy of that issue to this
thread...but even when a miscommunication has nothing to do with the
ASF, I would prefer that it is addressed before the proposal becomes a
project associated with Apache.

Cliff

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

[Sanjiva Weerawarana]

On Tue, 2005-12-20 at 23:18 -0500, Adam Peller wrote:
>
> 2) The other subproject is Zimbra itself, but there may be other runtimes
> here as well.  As you say, the main goal here is to provide layers of
> abstraction to hide the traditional browser tricks and quirk modes to make
> browser-based programming more productive, and Zimbra does this well.

Did you really mean all of Zimbra or just the toolkit part?? I believe
Zimbra includes an email client platform as well .. and something
they're pushing with a dual license model (which clearly does not sit
well with us once code starts coming in from other contributors).

Thanks for the long explanation!

Sanjiva.



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...