Re: Zope?

[Jason Cater]

For starters, GNUe is not a web-based application.  We will have some
web extensions to our tools, but it is not, nor ever will be, a
completely web-based solution. 

Aside from this general observation, it would be possible to have a
web-based application server as the backend. We've toyed with the idea
of supporting JBoss and (somewhat) Zope as backends, but nothing has
come of this as our resources are very limited.  

As anyone who follows our development knows, we use modular "adapters"
for everything we can -- including backends for our tools.  With little
effort, we support close to a dozen databases today. The same will
happen with middleware backends. GEAS is our priority, but I'm sure the
tools will eventually support these other options. 

I cannot speak for the GNUe Application Server folks (I am a client-side
tool developer). However, from my point of view, Application Server is
very much an over-used term that has little meaning these days.
"Application Server" can describe anything from a web portal to a
business rules server to a database proxy. It's just not a useful word
to compare applications. It's almost as useless as the term
"middleware".  Again, that term is a very broad, all-encompassing word
that gives little clue as to what role the application actually serves. 

I think a description for Zope would be "highly-extensible web-based
publishing environment that is Object Oriented in nature."  Err, wait,
that's basically what ZOPE stands for -- "Z Objects Publishing
Environment."  Sure, it's a type of application server, but I don't see
too much overlap in goals. 

GNUe also runs the risk when using the term "Application Server" of
confusing would-be developers.  We have a very specific focus with our
app server -- i.e., a business rules + data server.  Well, actually, I
envision a series of servers: "business rules/data server", "RBAC
authentication server","workflow server", etc. This may not be fully in
line with Reinhard's and Derek's views, but I have a feeling it is
close. 

Now, it could be feasible, I suppose, to reuse the very core of Zope as
our core and not use their higher-level content-specific layer. However,
from a practical standpoint, I truly think this would be more effort
than it's worth. For starters, we already have a strong core
(gnue-common) that would provide pretty much what the "core" of Zope
would provide . Also, Zope is a very complex piece of software to
develop on internally. From Zope 3.0's Wiki board:


   "You can't learn Zope in bite sized chunks; you must learn the 
   entire framework at once. You can't use familiar tools and
   techniques. It's hard to reuse code. The Zope development model (ie
   Products) often seem too heavy-weight. Zope products don't offer a
   good separation between logic and content."

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/VisionStatement


So what's my point with all this rambling? Basically, be wary of
comparing applications just because they both use the term "Application
Server."  My toilet paper dispenser is an application server.  So is my
refrigerator.  I try not to confuse the two, though. 

We've also been approached by the DotGNU folks about them reusing parts
of our Application Server for their .NET replacement. I think tossing
the "Application Server" phrase around is causing the same confusion in
this case.  What exactly is an application server to DotGNU? Is it the
same as GNUe's definition? What about Zope's?

I honestly think a better question would be "why isn't DotGNU considering using 
Zope as an Application Server?" as I see more overlap there than here. 

Now please bear in mind that several of us use Zope in our professional
settings. None of us are Zope core programmers, but we have done some
hefty sites using Zope. I am not IN ANY WAY putting down Zope as a
specialized application server. I use it everyday and absolutely love
it; but, I love it for what it is -- a web-based content server. I also
have to give credit where credit is due... Zope has been the leading
example of python programming for some time now. We directly benefit
from any contributions they've made back to the python language and
python's extensive standard library. 

Also, be judicious with your use of the word "Public Domain"... very
little (if any) of our or Zope's work is in the Public Domain. It's
almost always copyrighted. "Public Domain" is a specific legal term just like 
"Copyright" is. 

Well, that's my (not-so-) short thoughts on the matter. 

Jason Cater
GNU Enterprise
address@hidden


On Fri, 17 May 2002 09:44:46 -0700
"Todd Boyle" <address@hidden> wrote:

> My understanding is, that if Zope were the foundation of GNUE,
> it would not prevent or inhibit any of the higher goals of GNUE.
> In other words, that GNUE could be just as stable, secure,
> and well-performing using the "libraries" in Zope as with
> GNUE's native Python applications.
> 
> So, the general picture is that a Zope GNUE would be
> implemented by a larger number of users and wouldn't
> sacrifice any of GNUEs goals.   (I guess, those GNUE
> requirements not part of zcatalog would have been extensions
> on zcatalog for example.)
> 
> The general picture is also that a huge amount of work has
> already been done on the existing code, somehow, contributed
> to the public domain, by numerous developers within their existing
> matrix of needs, incentives etc.   This is quite a remarkable
> phenomenon, in itself and not to be messed with.  I would
> assume that if there were any calculus, among the existing
> developer community to switch to Zope they would have done
> it earlier.   In other words, they have looked at Zope and
> decided to do it themselves, the GNUE way.
> 
> I guess, I don't understand WHY the GNUe developers rejected
> Zope but that would be a very, very interesting information to
> me, and probably a lot of people, not the least being the Zope
> community.   Jason, Derek, Reinhard, if you have time, I'd appreciate
> a candid, even blunt report on this!   What are the top 3 or 4 or 5
> reasons why the GNUE developers, themselves, rejected Zope
> as well as, why they won't switch to Zope?
> 
> I'm going to guess that the main advantage: wider adoption and
> more users.  Main disadvantage: the cost of the migration or
> in other words, the developers just ain't gonna do it because
> they're getting what they need, they already donated once and
> that's that.   And by implication: the developers probably assume
> that the move to Zope might not bring in enough new developers
> to matter, or perhaps, the GNUE components are already
> sufficiently complete for the things the developers need and want?
> 
> Also---new members always have their own goals and desires,
> which puts stress on the existing web of desires that have
> already been reflected in a lot of code.  Therefore, whatever
> code emerged after the Migration to Zope would not perform
> the same mix of functions as today's GNUE.   (i.e. developers
> would lose some control over the final product)...
> 
> Another disadvantage that possibly results is, lots of unsophisticated
> Zope users would build hundreds of goofy addons, similar to
> the Excel macro phenomenon.  Administrators would basicallly
> lose platform control and control over data and control over the
> workflow out in the departments.  In 25 years in accounting and
> software I have seen this in SO many ways, as the controller
> fights the accounting or front office, as the Glass Room fights
> the PC, and today the CXOs who dominate todays' information,
> fight P2P.
> 
> Another disadvange of Zope is that anything that results in lots
> of code and dependencies on the Official Distribution of GNUE Zope
> would paralyze it, sooner or later.  Any good software company,
> eg Microsoft, needs to churn the code every 2-3 years to prevent
> the whole, vast community of VARs and users from forming
> a critical mass of resistance to modernizing the platform,
> 
> Todd
> 
> 
> 
> At 07:25 AM 5/17/02, Jason Cater wrote:
> >Hi Malek,
> >
> >This is certainly a valid question. Several of the core developers use 
> >Zope as web/portal servers at their places of work. GNUe is even switching 
> >to a Zope backend for our website.
> >
> >While it's true that Zope is an application server, it is our opinion that 
> >Zope is a specialized, targeted web application server -- it's targeted at 
> >serving web applications / content. Even their site says this:
> >
> >     "Zope is a leading open source application server,
> >      specializing in content management, portals, and
> >      custom applications."
> >
> >However, I could be way off base... sometimes free/open source projects 
> >are more general-purpose than they at first comes across. In any case, our 
> >tools are fairly modular in nature, so if someone wanted to use Zope as a 
> >backend, our tools should support it.
> >
> >I hope this was somewhat helpful.
> >
> >
> >Jason Cater
> >GNU Enterprise
> >http://www.gnue.org/
> >
> >
> >On Fri, 17 May 2002 11:23:28 +0200
> >"Malek Hadj-Ali" <address@hidden> wrote:
> >
> > > Hi everybody,
> > >
> > > I have a (maybe stupid) question, why aren't you guys using Zope as an
> > > application server?
> > > It has a lot of features that could be reused (ZCatalog, ZSQLCatalog, 
> > > ...),
> > > it's written in python, it has a big community of developper, and so on...
> > >
> > > Just curious
> > >
> > >
> > > Malek
> > >
> > > PS: please keep in mind I'm not a developper, so I don't understand
> > > immediately if there is some background incompatibility.
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Gnue mailing list
> > > address@hidden
> > > http://mail.gnu.org/mailman/listinfo/gnue
> >
> >_______________________________________________
> >Gnue mailing list
> >address@hidden
> >http://mail.gnu.org/mailman/listinfo/gnue