incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Peller <apel...@us.ibm.com>
Subject Re: AJAX Toolkit Framework Proposal
Date Wed, 21 Dec 2005 04:18:38 GMT
Hey Sanjiva!  Yeah, it's been a while.  I've been trying to follow your
projects and blogs over the years.  Sounds like all is going well.

No secret agendas here :)  Happy to answer.

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

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

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

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

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

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

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

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

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

Regarding Mozilla:

>Are they contributing code and/or committers too?

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

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

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

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

Regards,
Adam


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


Mime
View raw message