There is an 9 message thread on the hamilton/locomotive/enhydra lists perhaps of interest to Zopists: Zope was not originally included in the discussion but it should be and I made it so. It is a long thread and may not be of interest to everyone but those strategic planners at DC (Paul...et al) may want to reply to these lists to the very last message at the end from Brad Neuberg. Being that ZOPE is the best, IMHO, it only helps to let the world know! (I have separated messages with "*---" and much of the ">" quoted text is omitted shown with my "...") The involved lists: (With my post at the end) locomotive-dev-owner@locomotive.org ; hamilton-development@lists.microstate.com Another list in the group: (I'm not subscribed) enhydra@enhydra.org; *--- Hello Everyone: I am a new member of locomotive, enhydra, and Hamilton Application Sever projects. As a corporate developer, I need to focus my time on a single Application Server. I believe that we need to work together to merger these projects together to provide one single Application Server. I believe that we will not reach the full potential of the Open Source Model until there is a single project that everyone can focus on. Thanks, Jeff Duska <JeffDuska@kemet.com> *--- I've been thinking along the same lines as Jeff. I think it would be great to take all of the open-source pieces we have and create a best-of-breed application server. Thanks, Brad Neuberg VP of Technology, BaseSystem Inc.<brad@basesystem.com> *--- Given the current situation, for now, you'd be best off evaluating them and picking the one that best suits your needs. Use the right tool for the job, and all that. If you are interested in rolling up your sleeves and working on the design and implementation of an applications server (a long, sometimes tedious, demanding, but very challenging process), read on... ...

...

I believe that we will not reach the full potential of the Open Source Model ... I've been thinking along the same lines as Jeff. I think it would be

It's certainly an interesting idea, but there are some significant challenges ahead to anyone who would try to implement a merger: * The licenses for these products are probably incompatible. I'll address the issues for Locomotive Enhydra separately. Hamilton is currently distributed under the LGPL. This allows people to use Hamilton for both free and proprietary software, without worrying about "infecting" their code with a viral license like the GPL. Locomotive has an MPL-derived license. In their license FAQ, the Locomotive folks take this stance with respect to the LGPL: The LGPL takes a step in the right direction by addressing libraries, but we can not use it because the Locomotive is not by any definition a library, but is a server or platform designed to call other code. However, a quick look at the Locomotive documentation shows that it is, in fact, a sort of library: http://www.locomotive.org/docs/dev_guide_frames/dev_ch2.html#_Toc422816224 If you write code that extends an object from another package, or it uses objects from another package, that's use of a library. From the LGPL's definition of a library: A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. Sure, an application server has some kind of runtime that loads the applications that it runs, but at their hearts, applications servers are basically libraries of code. It's not clear to me the implications of mixing MPL-covered and LGPL-covered code. It might be possible, at least in one direction (LGPL'd code including MPL'd code). They do differ slightly on patent issues, and on the requirements for redistribution. From my initial reading of Leverage's version of the MPL, it looks like Hamilton might be able to use code from Locomotive, as long as we complied with the terms of the Locomotive Public License (make modifications to their code available, document all changes and their dates, and so forth), but that seems pretty messy to me. I would love to see Locomotive change their license to LGPL. That would allow code sharing between the two projects without restriction. The Locomotive folks currently can't use any of the Hamilton code in their product, because the LGPL demands that derived works be distributed under the terms of the LGPL. If you use LGPL'd code and distribute a modified version, you are not allowed to impose additional restrictions on your licensees. Section 10 of the LGPL states: 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. Enhydra uses a BSD-style license, including the obnoxious advertising clause (see <http://www.gnu.org/philosophy/bsd.html> for an explanation of why this is limiting.) We could incorporate Enhydra code into Hamilton, but then we'd have to state that we've done so in all of our marketing materials. (If you look inside the Hamilton sources, you'll see that we do incorporate some code from the World Wide Web consortium, that uses a license similar to the Enhydra license, but without the advertising clause. Because the W3C license does not impose additional restrictions on the copying, modification, or distribution of the code, we can incorporate it without any problems. We don't have any heartache over the terms of the W3C license). Even if you ignore the license problems, the architectural differences in the products differentiate them. The three products have vastly different implementations of similar ideas. They offer different levels of abstraction to application programmers. Merging the servers is not practical. The competition between the projects will benefit all of them, I think. There is room in this world for more than one Java application server (of course, it's to my benefit to plug Hamilton here :) Richard L. Bullington III <rbulling@microstate.com> Chief Technology Officer, The Microstate Corporation Phone: 703-591-9797 URL: http://www.microstate.com/ PGP key IDs: RSA: 0x93862305 DH/DSS: 0xDAC3028E *--- After looking through the different app servers, Locomotive seems to have the most extensive user management API, while Enhydra has good access to legacy data. Hamilton has the best license so far, as well as a good web-based resource management system. When I mean a best-of-breed app server I mean taking those portions of each app server that is their strong-suit and merging them together. So I would take Locomotive's user management API, combine it with Enhydra's legacy access APIs, grab a GPLed version of the Java Server Pages, GPLed LDAP stuff, and Hamilton's web-based management system. I wouldn't attempt to combine Locomotive's, Hamiltons, and Enhydras 'conceptual' development model (i.e. Steam, etc.). Rather, I would somehow choose which conceptual model seems to lead to the most productive results, with possibly some study on what tasks would be done with this new best-of-breed app server. Thanks, Brad Neuberg OpenPortal: where websites becomes discussions, and discussions become websites http://www.openportal.org "The geeks are not destroying creativity, but are re-inventing and re-invigorating it." -- Jon Katz ------------------ The internet routes around censorship, while the open-source community routes around proprietary protocols. *--- Hi, RB has a set of good arguments against combining the app servers re licensing issues. As an Architect and a software developer from Cobol to Turbo Pascal to Ada to C to Java, here are my observations. The competition among the products, instead of making them stronger, most probably will weaken them. Segmenting will happen, feature set will be distributed (pardon the pun !) i.e. one will have some set of good features while other will have some other set of desirable features. Another point is, if we concentrate our efforts into one unified product, that will grow much faster than three separate products. For example if we add a role-based-access-control/security system, we need not try to add it to all the three products. Another similar example is the EJB support 1.0 and later 2.0 with entity beans etc. Our efforts should be similar to the Linux movement (all working towards one product) than the Unix movement (many different flavors of the same product or products in the same market). I agree that the work to bring all the parties, licenses and products together will be difficult, but I think it has rewards too. We should probe at least to check the feasibility of such an endeavor. May be we can combine the good features, partition them to the three organizations (as keepers) and go forward. cheers Krishna Sankar <ksankar@gte.net> *--- I have been looking at enhydra and locomotive untill somebody on another thread mentioned hamilton. I have since downloaded your software. After going through a lot of the documentation I have the following questions: 1. Am I missing something here, I cannot seem to find a document which discusses how to construct a basic application with hamilton. I quess I can look at the xtras directory and figure it out. However, somesort of basic document would be great which just outlines the step required to build a "hello world" on top of hamilton. 2. Where does JSP fit into your current architecture (if anywhere atall). It seems all the application servers out there have some sort of system to seperate the presentation layer from the business logic. 3. What about session management. Java Web Server has extensive session management capabilities. It uses a LRU based system to keep sessions persistant if all the memory is used up. How is this different from your system. Are you using the JSDK session management functions of have developed your own architecture. If you have developed your own system do you support URL rewritting. Have you guys though about including gnujsp in your distribution (or atleast a system where an extern JSP implementation can be plugged in)! 4. Is there going to be any support for XML in the future? Once again would love to get my hands on more detailed documentation on how to write applications using hamilton. The white paper on your site is just one page. An interested developer, Vineet Vineet Jain <vinj@pacbell.net> *--- I find existing application servers too 'monolithic': they attempt to integrate and solve all problems. This leads to the classic problem with monolithic systems, which is that they don't plug and play with each other well. I propose that we break the best-of-breed pieces of the four menioned app servers (Enhydra, Locomotive, Hamilton, and Zope) into like 10 independent components and APIs that are loosely coupled. These could be Scripting Language, User Management, Persistance Storage, Directory Services, etc. The good thing about making loosely coupled sub-packages is that it would let us swap things in quickly (such as adding in a JSP module or mobile objects), and is also a great design for massive parallel development. Another advantage of this is that it allows for rapid re-use by other projects, which is one of the strengths of open-source, since it can lead to parallel mutation and evolution of concepts. I am already at work on such components, though not completely focused on app server stuff. I am currently cloning and reverse engineering into individual modules some of the Voyager SDK, as well as some best-of-breed user management APIs culled from IBM's WebSphere. I am going to release these under the GPL, but would feel completely fine giving copies to the four app servers. I have already cloned Voyager's Dynamic Aggregation, which is quite powerful for seperation of presentation and business logic and for design by composition, so if anyone wants that I'll give it to them. Thanks, Brad Neuberg VP of Technology, BaseSystem *--- Hi all, Just making some comments from the locomotive side of things.... ... My feelings here is that since we're all open source, it wouldn't hurt to try to figure out ways to work together. We all provide some functionality that the other's don't have- it would be nice to create interfaces and classes which would allow different pieces of our technology to work together. That would allow at least some of the kind of plug-and-play that brad has been talking about. I think I tried to get in touch with the enhydra people about this a while back, but didn't really get any response. We'd still love to work together with anyone that's willing- let us know what your thoughts are on how we can get this started. Also- we're hoping to work with the Java-Apache project to get a server framework off the ground that all java server programs may use. This discussion is just beginning- check out the java-apache-framework mailing list at java.apache.org ...

This allows people to use Hamilton for both free and proprietary software, without worrying about "infecting" their code with a viral license like the GPL.

My feeling is that the license should be the least of the worries. As far as I can recall, the locomotive folks went with the MPL type license because it was the most thorough. We had a couple lawyers look it over, and they told us of all the licenses, it provided Leverage Information Systems, the original Locomotive owner, with the clearest legal position on their relationship to the product. This was important for leverage, so that's the license we went with. We decided against the LGPL, I think, because it was simply too vague as to what kind of API level interface you could interact with the product without having also LGPL your code. And we thought that people would be less inclined to use a product that might force them to release their code under a strict license in the future than a product which did not. My feelings these days are actually to move farther in the direction of freedom, towards the BSD / apache style licenses. I think the product, as the result of a unified effort, should be able to stand on it's own, without any kinds of licensing issues to constrain or protect it. While that opens the product up to exploitation, it also provides it with the widest breadth of potential usage. That's of course my feelings- not necessarily the feelings of the Locomotive Project in general. Some specific licensing comments are below. Just to say again though- I think licensing is the least important reason for us not to collaborate. I understand that different design methodologies, or different goals, might keep us apart. I just don't see how licensing should. (Just my two cents- I'm a developer, not a lawyer, or a CEO. I care more that the code get's used than how is used or who uses it. Again, my personal opinion) ...

sure, an application server has some kind of runtime that loads the applications that it runs, but at their hearts, applications servers arebasically libraries of code.

The problem here was that the LGPL didn't tell us clearly enough where the line was for a prodcut that's not a library but has API level interfaces. ...

Locomotive Public License (make modifications to their code available, document all changes and their dates, and so forth), but that seems pretty messy to me.

I think that you can use loco code in Hamilton without telling locomotive.org, as long as you interact at a file-based level- that is you don't change any of the files you bring bring over from the loco- and you make the source to the loco code you use available. If you change any loco source files, I think you have to publish the changes to locomotive.org, or whoever the current owner of the loco code may be. I could be wrong, though- I'll forward this on to the other leverage people that know more for a definitive answer. ...

the terms of the LGPL. If you use LGPL'd code and distribute a modified version, you are not allowed to impose additional restrictions on your licensees.

This is reason enough for us, in my opinion, not to change to LGPL. We don't want people that use our code to have to conform to our license- we just want them to publish their use of our code under our license. We are not into the 'infection' of either LGPL or GPL based licenses. (At least I'm not- again, I'll forward this to the rest of the loco folks and see what they day) ...

The three products have vastly different

...

implementions of similar ideas. They offer different levels of abstraction to application programmers.

Agreed here- but that's not to say that we still can't work to together, at least to provide glue code that lets people use hamilton's functionality on top of a loco foundation, or enhydra's administration features with either of the other two. ...

Merging the servers is not practical. The competition between the projects will benefit all of them, I think. There is room in this world for more than one Java application server (of course, it's to my benefit to plug Hamilton here :)

This may be true too. I guess we'll just have to wait and see! Chris Kiernan Locomotive Application Server Project Chris Kiernan <ck@thespringfieldproject.com> *---

license in for the project. If each group is truly committed to make the step to Open Source, we should have no problem work together to discuss the best solution for the distribution license

At Microstate, we're big boosters of free software and like the marketing advantages the the Open Source concept brings us. We've chosen our license very carefully, to balance development and integration costs, and to give people using Hamilton the maximum amount of flexibility with what they do with the code, while ensuring that advances and changes to the core product benefit the community.

Brad said it best that we don't want to take force other projects together. Instead, we want to extract the superior pieces of functionality into a new design. We may find that none of these module do what we want, today. In this case, we would then add this functionality.

You're certainly free to start another project that is the super-duper, best-of-everything, application server, that takes its inspiration from the various servers out there. It's my opinion that the world needs tools that work now, and that people will use working code over waiting for a faraway framework any time. You might be interested in what the Java Apache group is doing towards creating a universal server framework <http://java.apache.org/>, if this is what really excites you.

If we do not combined our efforts, we will be reproducing the "wheel" This not the most effective use of our efforts. I would disagree with Richard competition argument, because all this combined product will be competing against Oracle, IBM, BEA, and many other products. Instead of helping, I expect it would fractionalizing the open source market for application servers. The reason project such as Linux and Apache are a success, is because they are working towards a common goal. There is no reason we could not have different distribution much like Red Hat and SUSE do with Linux.

One reason Linux and Apache have stayed so coherent, is that there were already very well-defined standards that they implemented. Linux sought to reproduce the system call interface of the UNIX kernel (in a better, faster, smarter, sort of way), and the Apache web server sought to implement the HTTP protocols, using the (at that time) well-known NCSA server as a base. In application servers, there are no overarching, clear standards to build on. Everyone takes a little bit of this or that, and crafts a product around it. Some of the features that people want are: * Connection to multiple data sources * Database connection caching * Security and User Management * Separation of business logic from presentation * Code lifecycle management * Persistent store for session data * Distributed server management * Page result caching * Load balancing * Fault tolerance * Automatic failover Look at any application server. It will have some of these features, but not all. Hamilton has support for five or six of these, depending on how you look at it (I'll leave the exercise of which are supported to the reader :). These features will be implemented in different ways, and have different underlying architectures. This is a big universe that has very few standards currently. Standards will probably emerge as the product category emerges. Servlet support has become mandatory in the last year. EJB's are emerging as an increasingly important API for an application server to support. The process that produced the Internet protocols (the IETF's "Working code and rough consensus" process) will help this area develop. Hamilton currently has working code, and a group of motivated developers that want to enhance it. Working code speaks far louder than good intentions. ---- Richard L. Bullington III <rbulling@microstate.com> Chief Technology Officer, The Microstate Corporation Phone: 703-591-9797 URL: http://www.microstate.com/ PGP key IDs: RSA: 0x93862305 DH/DSS: 0xDAC3028E *--- Since this discussion includes other "competitive" servers I would like to mention another server: www.zope.org which is: "Zope is a free, Open Source(tm) web application platform used for building high-performance, dynamic web sites." Disclaimer: I am a user of zope not affiliated with the developers although I have participated on the mail list and think that this is a SUPER server. I'd love to hear other opinions and this cross list pollination can only help the open source movement. -Bob OConnor bob@rocnet.com *--- Another app server is Zope, which is written in a scripting language called Python. Since a Java bytecode version of Python is now available under an open-source license called JPython, Zope can be considered to be another app server available to us. I have not played with it seriously, but it incorporates some interesting ideas and technologies. Could someone who is familiar with the Zope technology explain its benefits and cons to us? Brad Neuberg <brad@basesystem.com> **** Posts compiled by bob@rocnet.com