[Zope] Re: Moving towards a common goal
Robert OConnor
rocon@pivot.net
Wed, 24 Feb 1999 14:01:31 -0500
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