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