"Stephen McConnell" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > A couple of things/observations - first - who is Timothy? I have a good > idea of who you are because you and have exchanged a lot of messages > concerning Web/Merlin/Avalon/etc. But those discussion need to move to > [EMAIL PROTECTED] so that other people get to know you better. Second > observation - your doing stuff that is in my opinion the initial steps > we need to be taking towards what Avalon should be - namely a complete > service-oriented-architecture and platform fully enabling web-services > integration. >
Obviously, I've finally subscribed to this list, so hopefully this will help some get to know me. I split time working between the office and my home, and I only subscribe to these lists from home. So, don't be surprised if my posts spike at different times during the week. > > Here is my take ... neither Servak nor Henson's component come close to > what I see as the end-game. First off - neither solution provides the > level of integration I'm interested in. Secondly, they both focus on > the web-app as component whereas what I envisage is the plug to turn a > container into a web server for any component exposing web-awareness. I > do have problems with Servak in that I think it is attempting to > formalize a component/web-app relationship that I think is way too > limiting. Instead, I prefer to move forward with a single engine, and > in doing so, keep things fluid and flexible as we experiment with > total-integration. With that in mind I think Henson's work is a much > better launch point. > > There are a bunch of initiative happening at the moment concerning > embedding. In your case (viewpoint of a web-app component) that isn't > directly relevant, however, if we look at the > "container-becomes-webserver" scenario, then a web-engine facility > (container-side-component)will be needed asap - and the mechanisms for > exposure of that facility transparently to other web-aware components > will be introduced into the kernel. > Having a web server/servlet container built into into the kernel can be a powerful feature. But in domain that I work and operate in, the web server is just another transport mechanism for moving data between points. In the servers/apps that I build, the web server is but one gateway or portal by which transactions move in and out of the application. Equally (or maybe slightly less) important are the FTP and SMTP protocols. To me, all these "servers" provides a doorway into the container by which the same data or transaction enters the container and be handed off to other components for decryption/authentication, application of business rules, and finally generation of some acknowledgment or response. So, while evolution of a web service component to full integration with the container is an interesting endeavor, that represents only one piece of the portal puzzle to me. FTP and SMTP services are also important to me. > To help everyone here get an idea of what you have been doing I suggest > you post a patch to avalon-sandbox. This will confirm to people that > what we are talking about is really small, and, will provide an > opportunity for people to play. With that in place you mentioned that > you wanted to make a number of enhancements. You can do this though > patches. While this is somewhat painful in terms of process - it is the > "traditional mechanism" and will provide the opportunity for other > avalon-dev committers to see you action. > Correct, it will be somewhat painful, but if that represents a good place to start, then we'll start there. I'll pull together the latest version of JettyPhoenix, including the Ant build system, and post that some form of a zip or tar.gz file. Someone else can handle putting in the sandbox. In v1.3, I had removed the Phoenix BlockContext dependency, so I'd like to re-name the project Avalon-Jetty, since it technically can run in either Phoenix or Merlin. Look for this post maybe sometime over the weekend. > > My thoughts: > > 1. forget about incubation - its not relevant because we are not > trying to establish a new project or new community - this is about > contributing to Avalon > > 2. start firing away with patches (and patching include the possibility > of a > patch to avalon-sandbox) > > 3. assume that what you contributions (via patches) may change radically > as we > evolve the avalon-web solution (i.e. it's not a project, its just > part of > development of Avalon's containment platform) > > 4. assume that actions (1), (2) and (3) may be dangerous to you health > as you > may get sucked into something much bigger than what you had in mind > That is already quite obvious. ;) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
