subject:"AJAX Toolkit Framework Proposal"


Craig McClanahan wrote:


The Zimbra part of the proposal could, I suppose, be held to aim at that
goal.  If you believe proposing an Eclipse-only tooling story (apparently to
the exlusion of at least some folks in the Eclipse Foundation :-) forwards
this goal, I would suggest taking this part of the proposal back for some
serious editing.


Please read Adam's email that predated yours by a full 2.5 hours.

In any case, if you would like to participate in this project on a 
technical level, you would be more than welcome.


- Sam Ruby

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Craig McClanahan

On 12/21/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
>
> Craig McClanahan wrote:
> >
> >>From a software engineering viewpoint, focusing on a single tool
>
> Have you any other tools in mind?  Bring them on!

Actually, I don't -- tooling-specific adaptations of generic technologies
seem best fitted to the corresponding tool development communitiies, with
participation from all relevant parties in the generic technology
development discussions.

Apparently, neither do you, or this proposal would have made this explicit,
and you'd have had representatives of other tooling folks directly involved,
rather than being totally focused on Eclipse plugins and SWT
implementations.

Once again, let me state that the goal is to seed a non-exclusive AJAX
> community at the ASF.

The Zimbra part of the proposal could, I suppose, be held to aim at that
goal.  If you believe proposing an Eclipse-only tooling story (apparently to
the exlusion of at least some folks in the Eclipse Foundation :-) forwards
this goal, I would suggest taking this part of the proposal back for some
serious editing.

Craig

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Adam Peller

Craig,

Sam addressed the social engineering viewpoint; I'd like to talk about the
software side:

> Craig McClanahan wrote:
>From a software engineering viewpoint, focusing on a single tool as a
>delivery vehicle will tend to bias architectural and implementation
>decisions towards what is easy to express in that particular tool.

I think Sam already mentioned that the Eclipse-based tooling is just our
contribution.  And while we'd try to make that as robust and extensible as
possible, we would be by no means limited to one tool.  If that isn't clear
in the proposal, we should fix it.  (Eclipse is a delivery vehicle for the
tooling only, btw -- the browser is the delivery vehicle for the
applications developed)   You've got to start somewhere.  Some of the
proposed tooling might be independent of Eclipse, and possibly even
independent of the various AJAX runtimes.  As for what we've done in
Eclipse so far, we're trying our best to keep it platform neutral.
Mozilla, embedded in our tooling, is really the container you're developing
in, and even there we hope to offer browser choice; we just chose Mozilla
as a starting point because it's ubiquitous, offers excellent integration
points, is open source, etc.  Isn't it really the browser choice which can
introduce bias? (the very problem AJAX toolkits try to address?)  Certain
conveniences or widgetry in the tool itself might be geared towards what
Eclipse supports, but I'd hope that Eclipse would not impact the
applications you would develop.  I'll have to think about this some more.
If you have any examples, I'd very much like to hear them.

-Adam

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re AJAX-Toolkit-Framework-Proposal


Jesse Kuhnert wrote:


I chose tapestry as a web framework to use, and now contribute to, because I
thought I was making the best choice as far as design and overall
flexibility.(not to the detriment of other projects, just a personal
choice..)  It's a shame that all of the other considerations have to flow
into these descisions, but I'd be very broken hearted to see anything ~but~
Dojo being used in tapestry, as it is the only reason I thought I'd have
something to contribute to the project. I suppose that the incubation of
this proposal shouldn't affect us, but in reality I think it will.


Tapestry is actually a good counter example to your very argument.

The ASF exerts no pressure for people to pick Struts over Tapestry, or 
for Tapestry to merge with Struts.  Of course, if people were asked, 
they would prefer a reduced number of Java web application frameworks -- 
but this is the wrong question to ask.


Another example: Geronimo initially only supported Jetty, not the ASF's 
flagship servlet container: Tomcat.  Since then Geronimo and Tomcat have 
chosen to work together to make Tomcat an option - but to the best of my 
knowledge that wasn't imposed on anybody, and Jetty will remain an 
option for the foreseeable future.


- Sam Ruby

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re AJAX-Toolkit-Framework-Proposal

2005-12-21 Thread Jesse Kuhnert

Though I'm still very new to ASF (recently added to tapestry) and the goings
on of how everything works I thought I would voice my tiny little opinion
into the fray as well.

It seems that, at least from what I can tell, choosing a javascript library
is a very personal sort of thing for most people and that a lot of concern
stems from the very probable assumption that with an actual corporate
sponsor and seemingly having it sprung out of thin air the proposal to have
zimbra added will push a lot of people towards a technology platform that
many feel may not quite be the most ideal choice.

I chose tapestry as a web framework to use, and now contribute to, because I
thought I was making the best choice as far as design and overall
flexibility.(not to the detriment of other projects, just a personal
choice..)  It's a shame that all of the other considerations have to flow
into these descisions, but I'd be very broken hearted to see anything ~but~
Dojo being used in tapestry, as it is the only reason I thought I'd have
something to contribute to the project. I suppose that the incubation of
this proposal shouldn't affect us, but in reality I think it will.

Again, I don't know anything about most of the topics being discussed on
this list right now, only that I did spend a great deal of time evaluating
all js packages out there(that I could find) and overwhelmingly thought that
Dojo was the best choice by far. For all the reasons already mentioned,
packaging/support/testing/commercial quality/existing community/etc..How can
a reply be formed to all of these very impressive forward-thinking design
choices that simply says "oh that is neat, I'm sure we'll be able to add
that in once we're in apache"?? Don't people have to prove themselves
anymore?

:/

jesse

Re: AJAX Toolkit Framework Proposal


Craig McClanahan wrote:



From a software engineering viewpoint, focusing on a single tool


Have you any other tools in mind?  Bring them on!

Once again, let me state that the goal is to seed a non-exclusive AJAX 
community at the ASF.


In case it isn't perfectly clear: including Zimbra isn't intended to 
exclude Dojo.  Including Eclipse, doesn't mean to exclude NetBeans.  As 
Dims has pointed out, including IDE plugins is not new ground at the ASF.


- Sam Ruby

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Craig McClanahan

On 12/20/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
>
> Sylvain Wallez wrote:
> > Adam Peller wrote:
> [snip]
> > So the questions are:
> > - is the ASF the place for Eclipse extensions? I don't deny the ability
> > to _existing_ project to host their tooling, but this isn't the case
> here.
>
> As I mentioned, I was involved with these discussions.  The ASF doesn't
> tend to make these types of decisions based on the technical aspects of
> a project.  What impressed me about the people who were proposing this
> is that they were sincerely interested in the Apache License and
> collaboration model.


Belief in the Apache collaborative development model should certainly be a
prerequisite for acceptance into the Apache community (to me, that's the
thing that binds ASF as a community more strongly than anything else).  But
that, by itself, is not a compelling argument for combining these two
particular subprojects into a single proposal.  That strikes me as bad
software engineering, as well as bad social engineering.

>From a software engineering viewpoint, focusing on a single tool as a
delivery vehicle will tend to bias architectural and implementation
decisions towards what is easy to express in that particular tool.  It would
leave aside the little detail that not everyone interested in AJAX will be
using that tool, or will even be using Java.  I'd like to see the various
AJAX libraries, and the communities around them collaborate more ... but
that problem space is plenty big enough without figuring out bindings to
tool widgets, for a particular platform, at the same time.

>From a social engineering viewpoint, this particular combination of
subprojects would create a perception that Apache's support for AJAX is all
about what you can do in Eclipse.  That's too limiting a scope for what we
should be trying to achieve.  A better answer might be to separate the
tooling aspects from the framework aspects, and consider building a
community around "tools for building AJAX based applications" in general,
that consumes this technology but unoubtedly others as well, rather than
trying to  combine oil and water in the same project.

Craig

Re: "Closed for renovations" (was:Re: AJAX Toolkit Framework Proposal)

2005-12-21 Thread robert burrell donkin

On 12/21/05, Leo Simons <[EMAIL PROTECTED]> wrote:



> The ASF isn't very good at "saying no", at least not very loudly. All our
> processes are geared at "saying yes" the right way and only if we feel
> comfortable. It seems we have something to learn here, and its a bit scary
> since this may have further negative impact on the subject at hand (you can
> just imagine all the bile..."Man, this project really sucks! Even the ASF
> didn't want it, and they ship more crap than any other open source
> organisation!").

LOL

or maybe: "ASF has turned this project down! Must be great! We've
found the next JBoss." ;)

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread robert burrell donkin

On 12/21/05, Ted Leung <[EMAIL PROTECTED]> wrote:
>
> On Dec 20, 2005, at 12:19 PM, Sylvain Wallez wrote:
>
> > Sam Ruby wrote:
> >> Sylvain Wallez wrote:
> >>
> >> As a general rule, the ASF doesn't go out "inviting", people
> >> within the ASF either start a new project, or projects come to us.
> >
> > You're playing with words. Sure, there's no formal invitation
> > process. Now ASF members can approach projects they find
> > interesting and "suggest them to submit a proposal to the ASF", for
> > the greatest benefit of both the coming and existing ASF projects.
> >
> > Thinking more about it, the fact that the ASF isn't supposed to
> > invite projects seems to go against the ASF meritocratic rules. You
> > should not ask for being a committer: you are voted in when other
> > committers consider you deserve it. And you can reject the offer.
> > Same for membership. Why couldn't it also apply to projects that
> > already follow the Apache way and are of interest to the
> > Foundation's projects?
> >
> > On the other hand, proposals like this one, originating from
> > commercial entities, really look to me as "pushing the ASF door
> > open", even if the incubator is supposed to ensure community
> > diversity and healthiness before graduating as a real project.
>
> If we don't invite projects then we become driven by the projects
> that come to us, which have been overwhelmingly sponsored by
> corporate interests.   Saying we don't have an agenda is really
> saying that we're happy to accept someone else's agenda, which I am
> certainly not happy with.

one reason for not issuing formal invitations from the ASF is that
we'd need to create enough process to ensure this happens with
oversight and so on.

IMHO informal negotiations lead by interested members would be a
better approach. this is allowed ATM but perhaps isn't working too
well right now or maybe just takes longer...

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Raphaël Luta

Sam Ruby wrote:
> Raphaël Luta wrote:
> 
>
> Overall, there is clearly strong interest in AJAX at the ASF, whether it
> be based on Zimbra or Dojo or whatever.  Furthermore, the proposal needs
> to be revised, particularly to incorporate the people who have expressed
> an interest in participating and creating ties to other projects.
>

I completely agree that there's a strong interest in AJAX from many Apache
communities, Portals included. It's something many people in many communities
are trying to figure out how to best tackle, however so far I've never seen
Zimbra mentioned in an Apache community in this regard.

> ---
> 
>> Criteria
>> 
>>

>> * Community:
>>
>>   none
> 
> 
> A bit overstated.  There is a community, but it has yet to be incubated
> and certified as following the Apache way.
> 

I can't see any existing community described in the proposal, I can't find
any public forum about Zimbra AJAX toolkit and everything I get from Google is
press releases, whitepapers and conferences.
If you could point me to an existing online public community, I'll gladly admit
I am overstating the current situation.

>> * Core developers:
>>
>>   no existing Apache committer or Apache member
> 
> 
> That's the initial proposal.  The proposal was immediately was met with
> several volunteers.
> 

It was indeed met with interest from several Apache committers, that doesn't
make them core developers though since they are not part of the current
development effort.
It does show a potential for community building.

>> Warning signs
>> =
>>
>> * Orphaned products:
>>
>>   Apparently no
> 
> 
> I'm not certain what you are trying to say here.
>

Trying to express that the toolkit doesn't seem to be orphaned as it is probably
actively used by Zimbra other products.

>> * Homogenous developers/salaried developers:
>>
>>   Definitely yes, all work for 2 companies with strong hierarchical
>> ties in
>>   the proposed committer base
> 
> 
> Again, the proposal was immediately met with volunteers.  I will state
> that everybody involved fully understands that the current level of
> diversity certainly would not meet the incubator's exit criteria for a
> project - and everybody supports the goal of building a diverse community.
>

My point was more than given the huge number of initial committers I would
expect it to grow to at least 35-30 committers with all new committers from
external parties before such a community could be called "balanced".
Starting from scratch and getting to this level is a *huge* task, especially
if you don't have another established community as a userbase.

> 
> To help you see it another way, take a look at the following link:
> 
> http://ajaxian.com/archives/2005/12/apache_ajax_too.html
> 
> AJAX is hot.  People outside are watching.  IBM and Zimbra will
> undoubtably get a lot of press people asking questions.  My experience
> has been that such people are well trained in saying "no comment", but
> the fact is that there is interest, and at some point it makes sense to
> meet such interest with facts.
>

I'm seeing and am actually actively looking because Ajax has some
critical impact on web applications and portals in particular.
One of the key comments I frequently see is:

Why does  have to be in the ASF ?

and frankly I can't think of a good reason why the ASF would want to
kickstart a brand new AJAX community. Several other exists, are working
well and are compatible with our IP, why create something new within the
ASF rather than join those existing communities ?

>> As is, I can't see a single reason to support the proposal ans see
>> several to
>> vote a strong -1 on it in its current form :
>>
>> - The proposal is too large to incubate, it's hard enough to create a
>> community
>>   from scratch around a single well-defined goal and codebase, rolling 2
>>   together is suicide in my book.
> 
> 
> I don't mean to minimize the concern, but we have incubated larger.  As
> we have seen in this and other donations - IP lawyers are very
> interested in clearly delineating the precise origins of each component.
>  As such, we've overstressed the separate nature of these pieces.
> 
> Just to be clear: the goal is to build one community.
>

Yes we have incubated larger but not always to very good results and
tackling something with as many different pieces is definitely a big
challenge.

>> - I don't see any benefit for the ASF and several drawbacks (more
>>   hard work and strain on resources, possible PR complications,
>> additionnal
>>   strain on friendly relations with other OSS groups like Eclipse)
> 
> 
> There definitely is interest in AJAX at the ASF.  If not Zimbra, then
> Dojo.  And as Sanjiva and Dims have eloquently put it
> 
> I have no patience for any kind of "this space is mine, you keep to
> yours" type nonsense. I totally agree that the only discussion here
> should

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Garrett Rooney

On 12/21/05, Ted Leung <[EMAIL PROTECTED]> wrote:

> I'd love to have a good AJAX project here at Apache, but I'm not at
> all convinced that this is the best way to get it.   I also talked to
> Alex Russell at Dojo about coming to the ASF (at this year's OSCON),
> and the overhead thing was already on his radar.   Perhaps we ought
> to be more concerned about making ourselves attractive to projects
> like Dojo.  We already know that the corporations see the value of
> the Apache brand.   Ask yourself why a small innovative project like
> Dojo would rather stay out of the ASF.   Wouldn't they benefit more
> from the Apache name than IBM and Zimbra?   An Apache branded AJAX
> toolkit would be seriously looked at just because of the branding.
> I would hate to be a party to helping a so-so AJAX toolkit displace a
> really good one, just because the so-so one came to the incubator and
> the other one didn't.

+1

-garrett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX Toolkit Framework Proposal

2005-12-21 Thread Mike Milinkovich




> Big assumption right there. I'll assert there's a reasonable 
> chance I understand what's under the hood of the Eclipse 
> platform quite well. IIRC I helped the Equinox people decide 
> on what to put in there at some point...

Mea culpa. I was reacting to the comment about the "heavyweight IDE". We
often battle some misperceptions of the Eclipse technology stack, so it has
become a bit of a reflex. My apologies.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal


Raphaël Luta wrote:

Excellent post!  It is nice to see somebody take the time to review the 
actual proposal.


Overall, there is clearly strong interest in AJAX at the ASF, whether it 
be based on Zimbra or Dojo or whatever.  Furthermore, the proposal needs 
to be revised, particularly to incorporate the people who have expressed 
an interest in participating and creating ties to other projects.


---


Criteria


* Meritocracy:

  I don't believe it looking at the committer list.
  Who's going to argue with his VP of engineering ? To create a real
  meritocracy, you can't have an established hierarchy in the committership.


Valid concern - needs to be worked.


* Community:

  none


A bit overstated.  There is a community, but it has yet to be incubated 
and certified as following the Apache way.



* Core developers:

  no existing Apache committer or Apache member


That's the initial proposal.  The proposal was immediately was met with 
several volunteers.



* Alignment:

  no simple mission statement but trying two roll out 2 complementary
  sub projects into a single community.


My fault for not catching that one.  I have stated that the goal is to 
build a single community.  See below.



Warning signs
=

* Orphaned products:

  Apparently no


I'm not certain what you are trying to say here.


* Inexperience with open-source:

  Limited experience if I judge by the number of OSS related hits tied to the
  proposed committer names on Google. Only 3 names get some hits.
  You can also how Zimbra as a corp currently gets it here:
  http://www.zimbra.com/community/


Valid concern.


* Homogenous developers/salaried developers:

  Definitely yes, all work for 2 companies with strong hierarchical ties in
  the proposed committer base


Again, the proposal was immediately met with volunteers.  I will state 
that everybody involved fully understands that the current level of 
diversity certainly would not meet the incubator's exit criteria for a 
project - and everybody supports the goal of building a diverse community.



* No ties to Apache products:

  True


Again, immediately upon seeing the initial post, several people 
suggested a number of possible ties.



* Fascination with Apache brand:

  True, just see prc@ activity.


I understand how you could see it that way.  For those not on the PRC, I 
sent a draft email yesterday which essentially said that discussions 
were underway with the ASF and gave an overview of what AJAX is.


To help you see it another way, take a look at the following link:

http://ajaxian.com/archives/2005/12/apache_ajax_too.html

AJAX is hot.  People outside are watching.  IBM and Zimbra will 
undoubtably get a lot of press people asking questions.  My experience 
has been that such people are well trained in saying "no comment", but 
the fact is that there is interest, and at some point it makes sense to 
meet such interest with facts.



As is, I can't see a single reason to support the proposal ans see several to
vote a strong -1 on it in its current form :

- The proposal is too large to incubate, it's hard enough to create a community
  from scratch around a single well-defined goal and codebase, rolling 2
  together is suicide in my book.


I don't mean to minimize the concern, but we have incubated larger.  As 
we have seen in this and other donations - IP lawyers are very 
interested in clearly delineating the precise origins of each component. 
 As such, we've overstressed the separate nature of these pieces.


Just to be clear: the goal is to build one community.


- I don't see any benefit for the ASF and several drawbacks (more
  hard work and strain on resources, possible PR complications, additionnal
  strain on friendly relations with other OSS groups like Eclipse)


There definitely is interest in AJAX at the ASF.  If not Zimbra, then 
Dojo.  And as Sanjiva and Dims have eloquently put it


I have no patience for any kind of "this space is mine, you keep to
yours" type nonsense. I totally agree that the only discussion here
should be does ASF want to take this on or not, not on whether
Eclipse folks feel it "rightfully" belongs there or not.

and

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.


- There's no mentor yet ! Bad sign...


Again, two volunteers within moments of posting alone.


- The odds of this project of successfully exiting the Incubator based on the
  diversity of co

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Adam Peller

Sanjiva,

My bad. I just meant the AJAX toolkit portion of Zimbra.

-adam



   
 Sanjiva   
 Weerawarana   
 <[EMAIL PROTECTED]  To 
 ce.lk>general@incubator.apache.org
cc 
 12/21/2005 03:33  Andy Pflaum 
 AM<[EMAIL PROTECTED]>, Chris 
   Boni <[EMAIL PROTECTED]>, David 
   Boloker/Somers/[EMAIL PROTECTED], 
Krishna   
 Please respond to Akella/Austin/[EMAIL PROTECTED], Ross
   
  general  Dargahi <[EMAIL PROTECTED]>, Sam  
   Ruby/Raleigh/[EMAIL PROTECTED], scott
   
   dietzen <[EMAIL PROTECTED]>, 
   Craig Becker/Austin/[EMAIL PROTECTED],   
   
   Leugim A Bustelo/Austin/[EMAIL 
PROTECTED],  
   Becky Gibson/Westford/[EMAIL PROTECTED], 

   Javier H
   Pedemonte/Austin/[EMAIL PROTECTED], 
Donald  
   Sedota/Austin/[EMAIL PROTECTED]  
   
   Subject 
           Re: AJAX Toolkit Framework Proposal 
   
   
   
   
   
   




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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: "Closed for renovations" (was:Re: AJAX Toolkit Framework Proposal)

2005-12-21 Thread Bertrand Delacretaz


Le 21 déc. 05, à 12:01, Leo Simons a écrit :


On Tue, Dec 20, 2005 at 04:49:29PM -0800, Martin Cooper wrote:

Some comments:



On Wed, Dec 21, 2005 at 10:54:03AM +0100, Raphaël Luta wrote:

To me it raises all the possible incubation warning bells:




Same feelings here, I agree with Martin's and Raphaël's concerns.


...I feel a bit sorry for the Zimbra guys..


To me the right thing to do if you were an "outside" company trying to 
join the ASF with a cool project, would be to build interest inside the 
ASF first and to get to know each other.


In other words, if I were Zimbra (but I'm not ;-) I'd get involved with 
some ASF projects where my stuff makes sense (Cocoon, JSF, Tapestry, 
you name it) to show us how good that stuff is, and most importantly to 
build relationships before coming up with a proposal where we (or most 
of us at least) recognize no one.


(I hope) the ASF is (still) about communities, not primarily code.

-Bertrand


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: "Closed for renovations" (was:Re: AJAX Toolkit Framework Proposal)

2005-12-21 Thread Sanjiva Weerawarana

On Wed, 2005-12-21 at 03:01 -0800, Leo Simons wrote:
> 
> I have this urge to set up an "Under construction" sign on the incubator front
> page with a subtitle along the lines of "closed for renovations"...

+1, to give us a bit of soul searching time. We should put a cap on the
renovation time - 2 weeks seems ok to me given the holiday season.

[With lots of apologies to the proponents of the project :(.]

Sanjiva.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

"Closed for renovations" (was:Re: AJAX Toolkit Framework Proposal)

2005-12-21 Thread Leo Simons

On Tue, Dec 20, 2005 at 04:49:29PM -0800, Martin Cooper wrote:
> Some comments:

On Wed, Dec 21, 2005 at 10:54:03AM +0100, Rapha?l Luta wrote:
> To me it raises all the possible incubation warning bells:

Two convincing posts.

> In summary I see this proposal as a high risk, low value offer to the ASF
> and would definitely pass on it.

We might summarise other comments so far as concerns about a "low value" not
just for the ASF but for the larger open source community in general.

Hmm. This is a new thing for us here at the incubator. Eg we've seen "high
risk, low value" proposals before, but those were generally greeted with a
lack of interest in the problem space all-around. Judging by the amount and
length of the emails, there's a bunch of people really interested in this
AJAX thing.

The ASF isn't very good at "saying no", at least not very loudly. All our
processes are geared at "saying yes" the right way and only if we feel
comfortable. It seems we have something to learn here, and its a bit scary
since this may have further negative impact on the subject at hand (you can
just imagine all the bile..."Man, this project really sucks! Even the ASF
didn't want it, and they ship more crap than any other open source
organisation!").

I feel a bit sorry for the Zimbra guys being caught in the middle (in general
I have a hard time feeling sorry for IBM, because its, well, IBM, and too big
too have any feelings towards except "too big") of what is essentially the ASF
doing some soul-searching and navel-staring with regard to the incubation
process. I can fully imagine how the people that worked on this proposal spent
weeks in excitement at the prospect of joining up with the ASF and all the good
stuff that would come of it, and now they're getting a cold shower.

I have this urge to set up an "Under construction" sign on the incubator front
page with a subtitle along the lines of "closed for renovations"...

- LSD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Sylvain Wallez

Leo Simons wrote:

On Tue, Dec 20, 2005 at 04:14:22PM +0100, Sylvain Wallez wrote:

I'm quite puzzled by this proposal. As I understand it, its mainly about
a set of Eclipse plugins for Ajax applications and the Zimbra library
that, among other features, provides a set of SWT-like widgets.

How is that puzzling?

Because the proposal mixes two different concerns, the runtime and the
IDE (see the "subproject" and "no tie in" discussion) and because
generic tooling is something unusual at the ASF.

So the questions are:
- is the ASF the place for Eclipse extensions? I don't deny the ability to
_existing_ project to host their tooling, but this isn't the case here.

IMHO that's a very valid question to which the current answer from the incubator is "yes, if
there's sufficient interest from existing ASF members" with "sufficient" somewhat
under discussion. I'll suggest that changing the answer to that question should be tackled
independently of this proposal.

IANAL. But from talking with Cliff at AC it seems there's not neccessarily a
licensing barrier either.

That's not a licensing question, but more a general OSS community
question. The ASF isn't alone in the OSS world, and there has been some
recent precedents where incubating projects have made other OSS
organizations uncomfortable. I don't say the OSS world should be
technically partitioned (e.g. server-side at Apache and IDE at Eclipse),
but that we should at least try to play nice with other organizations
and coordinate our activities.

Back in August, Cliff proposed a few modifications [1] to the incubation
proposal process, and IMO the current proposal shows how much these
modifications are needed.

- why incubate an Ajax library that none of the current ASF projects
uses nor plans to use, unless I missed something?

for all the usual reasons. "ties with existing ASF projects" is a question
we sometimes ask but the rationale for even asking the question has never
been written down in an email before (I think). I think what you're "missing"
is 2 years of history in how we're doing incubation (which often involves
"stuff that no existing ASF project uses or plans to use" when incubation
started, like, ehm, Harmony, or Geronimo, or SpamAssassin, or ...)

(...)

See my answer to Sam: the current proposal is very different from
SpamAssassin or Harmony.

I personally feel that wanting to draw projects into the ASF *just* because
other ASF projects want to use that stuff is Pretty Bad(tm). It should be
easy and accepted and encouraged for ASF projects to use stuff that lives
and breathes outside of the ASF if you ask me.

Sure, and that's what many projects actually do (and you know how many
external dependencies Cocoon has!). Now I don't see why it is bad to
propose to an external project to join the ASF, to ensure more
visibility and long-term sustainability when that external project
already has a lots of merits and is used by several ASF projects.

This is a win-win situation: we help the growth and healthiness of the
external project, and by doing that we solidify the foundations on which
our own projects are built.

(...)

Hmm. I think your email is more puzzling to me than the original proposal :-)
(A heavyweight java-based IDE for doing what's essentially designed as
"lightweight" stuff...it seems easier to just fix the embed-java-in-the-
browser problem, like Stefano is doing with Piggy Bank...oh well...)

Hehe, this comment actually shows how confusing the proposal is: it's
not about embedding fat clients in the browser, but about on one side a
general-purpose IDE and on the other side a specific client-side library.

Sylvain

[1] http://tinyurl.com/bfaoy

--
Sylvain WallezAnyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Ted Leung



On Dec 20, 2005, at 12:19 PM, Sylvain Wallez wrote:


Sam Ruby wrote:

Sylvain Wallez wrote:

As a general rule, the ASF doesn't go out "inviting", people  
within the ASF either start a new project, or projects come to us.


You're playing with words. Sure, there's no formal invitation  
process. Now ASF members can approach projects they find  
interesting and "suggest them to submit a proposal to the ASF", for  
the greatest benefit of both the coming and existing ASF projects.


Thinking more about it, the fact that the ASF isn't supposed to  
invite projects seems to go against the ASF meritocratic rules. You  
should not ask for being a committer: you are voted in when other  
committers consider you deserve it. And you can reject the offer.  
Same for membership. Why couldn't it also apply to projects that  
already follow the Apache way and are of interest to the  
Foundation's projects?


On the other hand, proposals like this one, originating from  
commercial entities, really look to me as "pushing the ASF door  
open", even if the incubator is supposed to ensure community  
diversity and healthiness before graduating as a real project.


If we don't invite projects then we become driven by the projects  
that come to us, which have been overwhelmingly sponsored by  
corporate interests.   Saying we don't have an agenda is really  
saying that we're happy to accept someone else's agenda, which I am  
certainly not happy with.


Ted

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Sylvain Wallez


Martin Cooper wrote:

Some comments:
  




+1 to all your points.


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.
  


+1. And rather than a minority, this looks more like a silent majority 
to me.


Sylvain

--
Sylvain WallezAnyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Ted Leung



On Dec 21, 2005, at 12:56 AM, Sanjiva Weerawarana wrote:


On Tue, 2005-12-20 at 22:10 -0800, Cliff Schmidt wrote:

However, after having been on the other side of this discussion during
the Synapse startup with the hullabaloo caused by ObjectWeb folks, I
have no patience for any kind of "this space is mine, you keep to  
yours"

type nonsense. I totally agree that the only discussion here should be
does ASF want to take this on or not, not on whether Eclipse folks  
feel
it "rightfully" belongs there or not. (No Mike, I'm not saying you  
said

that!)


 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.


Indeed. However, the corporate interest of a foundation has much  
lesser
weight in my book than what other ASFers think in evaluating this  
stuff.


I don't think it's that simple.   There's also the corporate interest  
of IBM and Zimbra in bringing this to Apache.   Generally speaking, I  
consider any open source foundation to be more my ally than any  
corporation or group of corporations.   I've been doing a lot more in  
the broader open source community recently, and discovered that  
Apache is not universally well-regarded.  I have heard it suggested  
that we are becoming the Microsoft of open source.   If part of the  
core Apache values are around community, why shouldn't that extend to  
the broader open source community as well?


I'd love to have a good AJAX project here at Apache, but I'm not at  
all convinced that this is the best way to get it.   I also talked to  
Alex Russell at Dojo about coming to the ASF (at this year's OSCON),  
and the overhead thing was already on his radar.   Perhaps we ought  
to be more concerned about making ourselves attractive to projects  
like Dojo.  We already know that the corporations see the value of  
the Apache brand.   Ask yourself why a small innovative project like  
Dojo would rather stay out of the ASF.   Wouldn't they benefit more  
from the Apache name than IBM and Zimbra?   An Apache branded AJAX  
toolkit would be seriously looked at just because of the branding.
I would hate to be a party to helping a so-so AJAX toolkit displace a  
really good one, just because the so-so one came to the incubator and  
the other one didn't.


I haven't looked at the code in question and I'm not a Javascript  
expert by any means.   But if Martin's analysis of the codebase is  
correct, then I'd vote no.



Ted Leung  Blog: 
PGP Fingerprint: 1003 7870 251F FA71 A59A  CEE3 BEBA 2B87 F5FC 4B42


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Greg Stein

On Tue, Dec 20, 2005 at 04:49:29PM -0800, Martin Cooper wrote:
> Some comments:
> 
> 1) This appears to be two proposals rolled into one. One is to incubate a

Yup. And Adam responded with the dreaded "subproject" word.

We determined a good while back that "umbrella" projects are bad. So
*starting* a project with the notion of subprojects is not necessarily
a good thing. Thankfully, this proposal lumps them into one community
(while the umbrellas divided them, which was the primary failing). But
lumping these two (somewhat disparate) project spaces into one seems
like it could be a problem. Especially given words about "pluggable"
and "no special tie-in". So if there isn't intended to be any special
tie-in between the two sides, then why shove the two communities
together?

It would seem this proposal ought to be divided into two.

>...
> 2) Various comments have been made regarding multiple ASF projects
> addressing the same area being OK, and indeed a good thing. While I

Yeah, although that has (historically) been based on taking different
approaches to a problem space, rather than simply tackling it with
different lines of code. I seriously doubt the AJAX space is
well-developed enough to identify very different strategies which
would lead to it being "acceptable" to kickstart two competitive
projects at Apache.

We're also about community here, so I would *expect* that if Dojo
decided to arrive at Apache, then it would go in *this* community
rather than start a second. Keep the communities together and working
on the space. If there is a real determination that the two think
about the approach dramatically different(!), then okay... maybe two
projects, but I'm a bit doubtful.

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

I share this concern, and Sanjiva also agreed with your concern.

A *lot* of code has been arriving at the ASF and many companies have
been seeking to do PR around those contributions and activities. I've
been starting to lean to a mode where (maybe) we simply won't provide
quotes to third parties about code they've provided. If it isn't an
Apache project (yet), then why should we talk about it?

And yeah: arriving via the Incubator is also a neat way to avoid our
standard meritocratic process. Diversity is also a question, and
whether there is true diversity in thought rather than simply in
numbers of committers.

Is there a solution? Nothing objective, I'd think. Maybe the Incubator
should only accept projects which have already established themselves
as open source projects? But what do we do about brand new ideas that
people want to spin up within the Incubator? Or what about projects
that the ASF determines that it really wants to be involved with?
(J2EE and J2SE to name our two precedents) Should the Incubator just
handle small-ish projects that are software-granted and destined to
existing PMCs?

I don't have an answer, but I share your unease with the spate of
corporate contributions over the past year or so.

Cheers,
-g

p.s. for those on this list who are not familiar with my protocol, I'm
  sending this as [EMAIL PROTECTED] rather than my apache address; that
  means I'm speaking as "Greg" rather than in my official capacity;
  thus, don't read any ASF policy/leanings into the above.

-- 
Greg Stein, http://www.lyra.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Raphaël Luta

Martin Cooper wrote:
> 
> 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.
> 

You may be in the minority but you're not alone, I'll admit to being *very*
uneasy on this proposal.
To me it raises all the possible incubation warning bells:

Criteria


* Meritocracy:

  I don't believe it looking at the committer list.
  Who's going to argue with his VP of engineering ? To create a real
  meritocracy, you can't have an established hierarchy in the committership.

* Community:

  none

* Core developers:

  no existing Apache committer or Apache member

* Alignment:

  no simple mission statement but trying two roll out 2 complementary
  sub projects into a single community.

Warning signs
=

* Orphaned products:

  Apparently no

* Inexperience with open-source:

  Limited experience if I judge by the number of OSS related hits tied to the
  proposed committer names on Google. Only 3 names get some hits.
  You can also how Zimbra as a corp currently gets it here:
  http://www.zimbra.com/community/

* Homogenous developers/salaried developers:

  Definitely yes, all work for 2 companies with strong hierarchical ties in
  the proposed committer base

* No ties to Apache products:

  True

* Fascination with Apache brand:

  True, just see prc@ activity.

As is, I can't see a single reason to support the proposal ans see several to
vote a strong -1 on it in its current form :

- The proposal is too large to incubate, it's hard enough to create a community
  from scratch around a single well-defined goal and codebase, rolling 2
  together is suicide in my book.

- I don't see any benefit for the ASF and several drawbacks (more
  hard work and strain on resources, possible PR complications, additionnal
  strain on friendly relations with other OSS groups like Eclipse)

- There's no mentor yet ! Bad sign...

- The odds of this project of successfully exiting the Incubator based on the
  diversity of community criteria seem very low to me: there are too many
  initial committers and most of them will have strong internal communication
  channels which will be invisible from the community.

- I don't believe most of the proposed committers would get committership
  on their own merit and I would hate the Incubator to become an easy way to
  bypass the meritocratic model of the ASF: work at IBM and get a free
  committership when they donate the codebase to the ASF ! Most of the time
  you end up with paid-for-committers that only last as long as they're told
  to work on the project. (This is not pure paranoia ;) just look at Pluto if
  you want to see it in effect)

In summary I see this proposal as a high risk, low value offer to the ASF
and would definitely pass on it.

-- 
Raphaël Luta - [EMAIL PROTECTED]
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-21 Thread Leo Simons

Mike, dude...

On Tue, Dec 20, 2005 at 10:32:25PM -0500, Mike Milinkovich wrote:
> > Hmm. I think your email is more puzzling to me than the 
> > original proposal :-) (A heavyweight java-based IDE for doing 
> > what's essentially designed as "lightweight" stuff...
> 
> It seems that your understanding of the Eclipse platform needs some
> updating.

Big assumption right there. I'll assert there's a reasonable chance I understand
what's under the hood of the Eclipse platform quite well. IIRC I helped the
Equinox people decide on what to put in there at some point...

Alas, that's not what 99% of the post was about. Taking the expertise of one of
the posters to this mailing list in question on the second mail you send is 
curious,
but disregarding most of the other stuff being said is, again, much more 
puzzling.

- LSD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

On Tue, 2005-12-20 at 22:10 -0800, Cliff Schmidt wrote:
> 
> My second reason for asking was as a polite gesture towards the
> Eclipse Foundation, being another respectable, non-profit, open source
> organization. 

I have ABSOLUTELY nothing against the Eclipse Foundation or their
products; I'm myself a very happy Eclipse user myself and fully
appreciate that there's such a high quality free product available for
me!

However, after having been on the other side of this discussion during
the Synapse startup with the hullabaloo caused by ObjectWeb folks, I
have no patience for any kind of "this space is mine, you keep to yours"
type nonsense. I totally agree that the only discussion here should be
does ASF want to take this on or not, not on whether Eclipse folks feel
it "rightfully" belongs there or not. (No Mike, I'm not saying you said
that!)

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

Indeed. However, the corporate interest of a foundation has much lesser
weight in my book than what other ASFers think in evaluating this stuff.

I do share many of Martin Cooper's concerns about this project however,
especially the last one. 

Sanjiva.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Cliff Schmidt

On 12/20/05, Davanum Srinivas <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

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 
 <[EMAIL PROTECTED] 
 rg>To 
 Sent by:  general@incubator.apache.org
 [EMAIL PROTECTED]  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&#x

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Davanum Srinivas

Got it! thanks

-- dims

On 12/20/05, Mike Milinkovich <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Geir Magnusson Jr.



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  +1-203-665-6437
[EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX Toolkit Framework Proposal

2005-12-20 Thread Noel J. Bergman

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX Toolkit Framework Proposal




> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Martin Cooper

lugins.
>
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> >>>a

RE: AJAX Toolkit Framework Proposal


> > 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

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 Ped

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Davanum Srinivas

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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX Toolkit Framework Proposal

2005-12-20 Thread Noel J. Bergman

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX Toolkit Framework Proposal


> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX Toolkit Framework Proposal



> Hmm. I think your email is more puzzling to me than the 
> original proposal :-) (A heavyweight java-based IDE for doing 
> what's essentially designed as "lightweight" stuff...

Leo,

It seems that your understanding of the Eclipse platform needs some
updating. The Java IDE is definitely what we're best known for. But
underneath that IDE there beats the heart of a lightweight, OSGi-compliant
component system. 

It's rather like saying what the heck is the Apache web server doing with a
JVM project? Similar to Apache, at Eclipse there is the original namesake
project, which has matured to a community with a significant number (50++)
of different projects.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Sam Ruby


Mike Milinkovich wrote:

[snip]


(I appreciate that you were not directly engaged with Eclipse prior to this
proposal being made public.)


[snip]


The last talk we had with IBM concerning this project was on October 20th


First, thank you very much for posting posting here.  I'm confident that 
together we can work through this.  Apparently, neither of us have a 
complete history.


Meanwhile:

There is some code posted at http://people.apache.org/~rubys/ajax/

There is a proposal posted at http://tinyurl.com/9ctml

I posted why I believe that a single cohesive community centered around 
a codebase with a single, liberal, sub-licenseable license would be a 
good thing.


At least one ASF member has +1'ed that reasoning.

Care to make an equally concrete proposal?

In particular, why would taking Solomon's advice and dividing the child 
in half be benefitial to anybody?


- Sam Ruby

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: AJAX Toolkit Framework Proposal



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

Sam,

This is absolutely incorrect. If you were surprised, you were misinformed.
(I appreciate that you were not directly engaged with Eclipse prior to this
proposal being made public.)

But we categorically deny the assertion that discussions were settled or
that this proposal was anything other than a complete and unpleasant
surprise to Eclipse.

The last talk we had with IBM concerning this project was on October 20th
and was to the affect that the runtime components would go to Apache and the
tools components would go to Eclipse. Runtime at Apache, tools at Eclipse. A
pattern we have all seen executed succesfully before. 

An email from me to IBM regarding the status of this proposal dated Dec.
15th went unanswered until 6:15 ET this evening, after this proposal was
launched at Apache, and this conversation on the mailing list ensued.

What or who made you think discussions were "settled"? 

Mike Milinkovich
Executive Director,
Eclipse Foundation, Inc.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Leo Simons

On Tue, Dec 20, 2005 at 04:14:22PM +0100, Sylvain Wallez wrote:
> I'm quite puzzled by this proposal. As I understand it, its mainly about 
> a set of Eclipse plugins for Ajax applications and the Zimbra library 
> that, among other features, provides a set of SWT-like widgets.

How is that puzzling?

> Also, this proposal pops up right after I mention on members@ that 
> several projects at Apache are using or plan to use Dojo [1] and that we 
> talked about inviting them. I sincerely hope this is just a coincidence.

Why? Even though it seems to be (and is likely to be since the proposal
looks like it took some preparing), why would lack of coincidence between
these events neccessarily be bad? If Sam were to have mentioned to the
guys working on this proposal something along the lines of "dudes. Several
ASF peeps seem to be getting more interested in AJAX stuff. You should
hurry up a bit with that proposal of yours" that would've pretty much made
sense to me. Note: Sam specifically said he did not say something like that
at all.

> So the questions are:
> - is the ASF the place for Eclipse extensions? I don't deny the ability 
> to _existing_ project to host their tooling, but this isn't the case here.

IMHO that's a very valid question to which the current answer from the
incubator is "yes, if there's sufficient interest from existing ASF
members" with "sufficient" somewhat under discussion. I'll suggest that
changing the answer to that question should be tackled independently of
this proposal.

IANAL. But from talking with Cliff at AC it seems there's not neccessarily
a licensing barrier either.

> - why incubate an Ajax library that none of the current ASF projects 
> uses nor plans to use, unless I missed something?

for all the usual reasons. "ties with existing ASF projects" is a question
we sometimes ask but the rationale for even asking the question has never
been written down in an email before (I think). I think what you're "missing"
is 2 years of history in how we're doing incubation (which often involves
"stuff that no existing ASF project uses or plans to use" when incubation
started, like, ehm, Harmony, or Geronimo, or SpamAssassin, or ...)

(...)

I personally feel that wanting to draw projects into the ASF *just* because
other ASF projects want to use that stuff is Pretty Bad(tm). It should be
easy and accepted and encouraged for ASF projects to use stuff that lives
and breathes outside of the ASF if you ask me.

(...)

Hmm. I think your email is more puzzling to me than the original proposal :-)
(A heavyweight java-based IDE for doing what's essentially designed as
"lightweight" stuff...it seems easier to just fix the embed-java-in-the-
browser problem, like Stefano is doing with Piggy Bank...oh well...)

- LSD

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

On Tue, 2005-12-20 at 18:27 -0500, Sam Ruby wrote:
> 
> 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.

+1.

> Life is hard enough as is.

:)

> P.S.  If this isn't complicated enough, there is a third party: Mozilla 
> involved.  At least there the line seems somewhat clearer.

Are they contributing code and/or committers too? 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?)

Sanjiva.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

On Tue, 2005-12-20 at 09:03 -0500, Adam Peller wrote:

Hi Adam! Haven't run into you since the early BSF days .. boy that was
like 7 years ago??! Looks like you're doing well and keeping busy ...
good!

I have some questions on the proposal:

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

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. 

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? 

If its an alternate client platform, can you expand a bit on plans to
build stuff with it? (Again you can reply with "Not your damned business
as it has nothing to do with the incubation process" but I'm just
looking for more info.) 

> 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

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?

The reason I'm asking is obvious .. I'd like you to use Axis2/C and
Axis2/Java for that part :). If the first part is about an alternate
client platform then I imagine you'd want to use Axis2/Java and plug it
into Rhino (obviously you can as-is but a more native binding would of
course be nicer). We already have the start of a Rhino provider BTW
(courtesy of Sylvain during ApacheCon!).

We've already started on a PHP binding for Axis2/C and would like to see
folks bind it to as much other stuff out there as possible. That way you
get a full function SOAP stack on the browser .. so instead of just
getting a bit of SOAP (which BTW doesn't make much sense; then one might
as well do pure XML/HTTP(S) and be happy and lighter) you get the whole
deal. 

Sanjiva.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Sam Ruby


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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Kenneth Tam

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.

On 12/20/05, Cliff Schmidt <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 sp

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Cliff Schmidt

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 <[EMAIL PROTECTED]> 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
> o

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Dan Diephouse


Sylvain Wallez wrote:
- why incubate an Ajax library that none of the current ASF projects 
uses nor plans to use, unless I missed something?


It is a valid question, but it is also valid to point out that the 
ASF has projects as diverse as TCL and SpamAssassin.


The situation is very different here: several projects are integrating 
Ajax features and incidentally found that they were considering the 
same framework for that purpoe. Whereas none of the ASF projects was 
already envisioning close integration with a spam filter when 
SpamAssassin came to Apache.


That could even end up with the funny (ahem) situation where Apache 
has an Ajax framework that isn't used by its Ajax-enabled server-side 
frameworks. Doesn't it sound weird?


I don't think this is weird at all. This may be off topic (or missing 
the point), but why do the ASF projects have to be one coherent product 
suite? Do they have to all tie together?  Sure tie-ins are great, but 
not everything needs to be related or play nice together. We have plenty 
of examples of competing projects (see struts, beehive, turbine, 
tapestry, etc).


I think Sam summed it up great when he said:

What is more important is considerations that the code be licensed 
with the Apache Software License (not dual licensed, like Dojo), that 
the committer bases be diverse, and operate in an open and 
collaborative model.

I think this is right on with the ASF philosophy [1]:

"""
While there is not an official list, these six principles have been 
cited as the core beliefs of philosophy behind the foundation, which is 
normally referred to as "The Apache Way":


   * collaborative software development
   * commercial-friendly standard license
   * consistently high quality software
   * respectful, honest, technical-based interaction
   * faithful implementation of standards
   * security as a mandatory feature


I think there is a space for any and all projects that meet the above 
criteria.


Cheers,
- Dan

1. http://www.apache.org/foundation/how-it-works.html#management

--
Dan Diephouse
Envoi Solutions LLC
http://netzooid.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Sylvain Wallez


Sam Ruby wrote:

Sylvain Wallez wrote:

Adam Peller wrote:

AJAX Toolkit Framework Proposal   


I'm quite puzzled by this proposal. As I understand it, its mainly 
about a set of Eclipse plugins for Ajax applications and the Zimbra 
library that, among other features, provides a set of SWT-like widgets.


Yes.

Also, this proposal pops up right after I mention on members@ that 
several projects at Apache are using or plan to use Dojo [1] and that 
we talked about inviting them. I sincerely hope this is just a 
coincidence.


Completely a coincidence.  I've been aware of the plan to submit this 
proposal for several weeks, and hadn't seen your post until you 
mentioned it.  I also had a conflict that precluded me from coming to 
the ApacheCon.


As a general rule, the ASF doesn't go out "inviting", people within 
the ASF either start a new project, or projects come to us.


You're playing with words. Sure, there's no formal invitation process. 
Now ASF members can approach projects they find interesting and "suggest 
them to submit a proposal to the ASF", for the greatest benefit of both 
the coming and existing ASF projects.


Thinking more about it, the fact that the ASF isn't supposed to invite 
projects seems to go against the ASF meritocratic rules. You should not 
ask for being a committer: you are voted in when other committers 
consider you deserve it. And you can reject the offer. Same for 
membership. Why couldn't it also apply to projects that already follow 
the Apache way and are of interest to the Foundation's projects?


On the other hand, proposals like this one, originating from commercial 
entities, really look to me as "pushing the ASF door open", even if the 
incubator is supposed to ensure community diversity and healthiness 
before graduating as a real project.


In any case, the ASF is not exclusionary: if there was interest Dojo 
could be added to this proposal, or could pursue a separate proposal.


Right. Now I don't consider starting a proposal war to be the best thing 
to do. Especially considering that one of the Dojo devs told me "Those 
[the ASF benefits] are all good things, however the political and 
organizational overhead of the ASF appears huge". Bingo.



So the questions are:
- is the ASF the place for Eclipse extensions? I don't deny the 
ability to _existing_ project to host their tooling, but this isn't 
the case here.


As I mentioned, I was involved with these discussions.  The ASF 
doesn't tend to make these types of decisions based on the technical 
aspects of a project.  What impressed me about the people who were 
proposing this is that they were sincerely interested in the Apache 
License and collaboration model.


While the Eclipse development model is certain a valid one, it is 
different in a number of significant ways from the ASF.  Suffice it to 
say that I am partial to the way the ASF does business.


Ok. Now some of the planned features seems to directly overlap with 
what's already in webtools (e.g. the JavaScript editor), and this 
project would be the first one at the ASF in the general IDE tooling 
category, which is what Eclipse is all about.


Sure, the development models are different and Apache cares about 
community and not technical details, but this seems weird anyway and I'm 
wondering if that won't turn into an OSS organizations war which would 
certainly be detrimental to all of us.


In other words: why isn't this IBM-originated generic Eclipse tooling 
donated to the Webtools project, that also originated from IBM?


- why incubate an Ajax library that none of the current ASF projects 
uses nor plans to use, unless I missed something?


It is a valid question, but it is also valid to point out that the ASF 
has projects as diverse as TCL and SpamAssassin.


The situation is very different here: several projects are integrating 
Ajax features and incidentally found that they were considering the same 
framework for that purpoe. Whereas none of the ASF projects was already 
envisioning close integration with a spam filter when SpamAssassin came 
to Apache.


That could even end up with the funny (ahem) situation where Apache has 
an Ajax framework that isn't used by its Ajax-enabled server-side 
frameworks. Doesn't it sound weird?


What is more important is considerations that the code be licensed 
with the Apache Software License (not dual licensed, like Dojo), that 
the committer bases be diverse, and operate in an open and 
collaborative model.


C'mon! The incubation process is meant to solve licence and IP problems. 
Zimbra is MPL & ZPL(?), and the IBM contribution is "Licensed Materials 
- Property of IBM"!!


The Dojo peeps dual-licensed their stuff to allow the widest 
distribution possible [1], and have a development model very close to 
the Apache way, with active user and

Re: AJAX Toolkit Framework Proposal

Sylvain -

Sylvain Wallez wrote:
>So the questions are:
>- is the ASF the place for Eclipse extensions? I don't deny the ability
>to _existing_ project to host their tooling, but this isn't the case here.

The framework is composed of tools that happen to use Eclipse for a
runtime, much like Java-based projects use a JVM.  As Sam stated, hopefully
it's the function that's of interest more than the platform, though I can
understand that this is not a typical proposal. The framework is only one
component of the project; runtime libraries and other AJAX-based utilities
(not tied to Eclipse) can find a home here also.

>- why incubate an Ajax library that none of the current ASF projects
>uses nor plans to use, unless I missed something?

What we hope to achieve is to form a community around AJAX. The tools we
put forth, we believe, will be helpful contributions towards that
community, but others are welcome. AJAX is likely to indirectly drive
Apache-based servers, and direct integration between AJAX and existing
Apache projects is certainly possible -- MyFaces is one such example.
Already we are building on top of integrated support for Tomcat to support
J2EE-based projects, and providing extensible tooling is key to the
architecture, so we should look for more integration points.

As for Dojo, we're very impressed with the project also.  The tooling
framework we offer is extensible and even comes with tooling to create the
tooling -- something I didn't get into in the proposal, but it's basically
a wizard-driven UI to make it easier to get at least basic support for
toolkits.  Custom features would require real coding.

-Adam

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

Hi Martin.

Although I confess to know little about MyFaces, I'd imagine your AJAX
components could work well within our tooling environment and that custom
extensions to support them are possible.  Out of the box (or with minimal
effort, at least) you should get some integrated JS support in JSPs, have
access to a debugger, snippets, and some other generic web tooling.  What
other sorts of tooling on the client do you think might help the MyFaces
project?

Also, perhaps some cross-polination with other toolkits, such as Zimbra and
Rico, could prove helpful, whether code is used directly or if just some of
the patterns prove useful?

Regards,
Adam




   
 Martin Marinschek 

To 
   general@incubator.apache.org
 12/20/2005 09:54   cc 
 AM
   Subject 
   Re: AJAX Toolkit Framework Proposal 
 Please respond to 
  general  
   
   
   
   




I'm very interested in this.

Even though I am not an Apache member (so no potential mentor ;) I'd
be very interested in what this project means for the Apache
MyFaces-javascript and AJAX integration.

regards,

Martin

On 12/20/05, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> Adam
>
> I offer to help mentor this.
>
> Paul
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> [EMAIL PROTECTED]
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> On 12/20/05, Adam Peller <[EMAIL PROTECTED]> 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

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Sam Ruby


Sylvain Wallez wrote:

Adam Peller wrote:

AJAX Toolkit Framework Proposal   


I'm quite puzzled by this proposal. As I understand it, its mainly about 
a set of Eclipse plugins for Ajax applications and the Zimbra library 
that, among other features, provides a set of SWT-like widgets.


Yes.

Also, this proposal pops up right after I mention on members@ that 
several projects at Apache are using or plan to use Dojo [1] and that we 
talked about inviting them. I sincerely hope this is just a coincidence.


Completely a coincidence.  I've been aware of the plan to submit this 
proposal for several weeks, and hadn't seen your post until you 
mentioned it.  I also had a conflict that precluded me from coming to 
the ApacheCon.


As a general rule, the ASF doesn't go out "inviting", people within the 
ASF either start a new project, or projects come to us.


In any case, the ASF is not exclusionary: if there was interest Dojo 
could be added to this proposal, or could pursue a separate proposal.



So the questions are:
- is the ASF the place for Eclipse extensions? I don't deny the ability 
to _existing_ project to host their tooling, but this isn't the case here.


As I mentioned, I was involved with these discussions.  The ASF doesn't 
tend to make these types of decisions based on the technical aspects of 
a project.  What impressed me about the people who were proposing this 
is that they were sincerely interested in the Apache License and 
collaboration model.


While the Eclipse development model is certain a valid one, it is 
different in a number of significant ways from the ASF.  Suffice it to 
say that I am partial to the way the ASF does business.


- why incubate an Ajax library that none of the current ASF projects 
uses nor plans to use, unless I missed something?


It is a valid question, but it is also valid to point out that the ASF 
has projects as diverse as TCL and SpamAssassin.


What is more important is considerations that the code be licensed with 
the Apache Software License (not dual licensed, like Dojo), that the 
committer bases be diverse, and operate in an open and collaborative model.



Sylvain

[1] http://www.dojotoolkit.org/


- Sam Ruby

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Sylvain Wallez


Adam Peller wrote:

AJAX Toolkit Framework Proposal
  


I'm quite puzzled by this proposal. As I understand it, its mainly about 
a set of Eclipse plugins for Ajax applications and the Zimbra library 
that, among other features, provides a set of SWT-like widgets.


Also, this proposal pops up right after I mention on members@ that 
several projects at Apache are using or plan to use Dojo [1] and that we 
talked about inviting them. I sincerely hope this is just a coincidence.


So the questions are:
- is the ASF the place for Eclipse extensions? I don't deny the ability 
to _existing_ project to host their tooling, but this isn't the case here.


- why incubate an Ajax library that none of the current ASF projects 
uses nor plans to use, unless I missed something?


Sylvain

[1] http://www.dojotoolkit.org/

--
Sylvain WallezAnyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Martin Marinschek

I'm very interested in this.

Even though I am not an Apache member (so no potential mentor ;) I'd
be very interested in what this project means for the Apache
MyFaces-javascript and AJAX integration.

regards,

Martin

On 12/20/05, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> Adam
>
> I offer to help mentor this.
>
> Paul
>
>
> --
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://bloglines.com/blog/paulfremantle
> [EMAIL PROTECTED]
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> On 12/20/05, Adam Peller <[EMAIL PROTECTED]> 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
>

Re: AJAX Toolkit Framework Proposal

2005-12-20 Thread Paul Fremantle

Adam

I offer to help mentor this.

Paul


--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

On 12/20/05, Adam Peller <[EMAIL PROTECTED]> 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
> a

AJAX Toolkit Framework Proposal