[ANN] SkunkWeb 3.0 Released!

[Drew Csillag]

On Fri, Aug 24, 2001 at 05:43:35PM +0400, Oleg Broytmann wrote:
> On Fri, 24 Aug 2001, Drew Csillag wrote:
> > Funny you mention it...  The beginnings of the SkunkWeb FAQ are here:
> > http://skunkweb.sourceforge.net/FAQ.html
> 
>    Ouch! Not so good, as I though before, at least for Zope. Whether your
> Mason/Webware observation is good or not so good - I cannot decide, but
> you've missed Zope almost completely :(
> 
>    Let me say a few words. Don't get me wrong - I am not against SkunkWeb.
> But your review should be more accurate. Let me try to argue and improve
> it.
> 
> > Like Webware, Zope uses a threaded model instead of a forking model
> 
>    Forking Zope would be an issue. It is too heavy.

On an SMP machine though, this kills performance because of the Python
Global Interpreter Lock.  It will only use a minute portion of the
other CPUs.  So if you're going to run Zope, basically don't bother
with SMP, you'd be wasting your money.  

> > DTML bites. It hits on making it easy to do easy things, but is too
> > constraining for the expert because you don't have the full flexibility
> > of Python in the tags.
> 
>    DTML is presentation language. Don't mix logic and presentation. If you
> need Python - just use Python, not DTML.

Well, but there is something called presentation logic.  Why have to
mash all of the presentation logic into modules when it's really
simple stuff.  Putting HTML in such cases into Python modules makes
life for the more techie guys in the shop hell because the front end
web people always want to change it and if it's in the Python code,
the techie people have to do it, so putting it in the templates makes
more sense, since this way, they can change it themselves.

> > I know that they are working on their next templating language (ZTL)
> 
>    ZPT - Zope Page Templates. It is not "next", it is just another,
> different approach. But still - if you need Python - use Python, do not
> program in ZPT.

I'll fix that.  ZPT still is quite ugly though.  I still argue the
point though: why can't I have my cake and eat it too?

> > Many people have written about how having the templates in the ZODB
> > instead of a filesystem can be a pain because you can't use all of your
> > usual filesystem tools/editors/etc.
> 
>    Yes, this is correct. Zope Corporation has a plan to move those objects
> into OS filesystem.
> 
> > Extending Zope is complicated
> 
>    Arguable. For simple extensions there are ZClasses. And writing a simple
> Python Product (module, component) is not a hard task. And even for more
> complicated Products Zope has a very nice API/classes/etc, so you don't
> nned to program everything. You already have persistent, web interface,
> etc.

Simple extensions of course should be simple, and are.  I guess the
kind of extensions I'm thinking of are things like writing a url
translation (of the english->spanish and back variety) scheme.  Not so
easy any more.  Or how about pull the source of templates from archive
files instead of ZODB (or the filesystem in the case of SkunkWeb)?

> > SkunkWeb (like Webware) was designed to be easily extendible and
> > customizable.
> 
>    I want to read more on this! How to write a DB connector? a module? an
> object to be published?

First of all, SkunkWeb is not primarily an object publisher.  When you
go to a web page, it's just a template.  Thinking about publishing
objects just complicates matters unnecessarily.  Yes, you can publish
objects by means of doing remote component calls, so in that respect,
publishing the object is a matter of writing a data component (which
is an absolute no-brainer).

Writing a DB connector is a breeze.  See the postgresql service in
SkunkWeb/Services.  Given it uses the PostgreSQL module in pylibs, but
most of that pylib is actually unnecessary (the ImmutableDict and
ResultList classes can go right into the trash, just haven't gotten
there yet).  In the really simple case where you don't care about
connection caching, you can just use the database-specific driver
(e.g. DCOracle, pgdb, etc.) code directly since there are no threading
issues to be concerned with.  Connection caching is really the only
thing that the DB connectors do (the Oracle connector can cache stored
procedure signatures too).

A module in SkunkWeb is just that: a module.  Just import it and do
stuff with it.

> > To call arbitrary code from Zope templates, you have to create Python
> > Method objects, which let's be honest, is a pain.
> 
>    Where is the pain?

I just want to import and call a function, not have to go through the
admin interface to say what functions people can call.  I want to
reduce the amount of work I (or others for that matter) have to do to
get the site up, running and fast.

> > STML has an import tag
> 
>    Insecure?

You don't trust the people who build the website for your company?
The trust models of Zope and SkunkWeb diverge significantly here.
With SkunkWeb, we assume if you have access to the filesystem to put
templates and/or modules on the server to begin with, we can trust
you.  Zope only trusts the administrators.  SkunkWeb was designed with
the idea that you have people who need to build a fast scalable web
site quickly.  Artificially restricting what your web people can do
only slows things down (both development and runtime).

> > I may be wrong on this one, but I don't think that Zope allows you to
> > cache the output of a template.
> 
>    There are cacheing Products.

But caching in a high-performance web serving environment is
absolutely central or you burn CPU (the app server's or the database
server's) like it's going out of style.

> > Modularity. It's pretty difficult to pull the cool bits out of Zope
> 
>    It is pretty easy to use ZServer, or ZODB, or DTML, or ZPublisher
> outside of Zope.

ZPublisher and DTML yes, but the others didn't used to be (keep in
mind the SkunkWeb project started 3 years ago when Zope was still
Principia).

Ok, that being the case though, for example, how much Zope code could
reasonably be used outside of Zope?  In SkunkWeb, only 6k lines is
SkunkWeb specific, the other 20k+ lines of code are things you can
totally use without using SkunkWeb.

>    Now few words about Zope. Zope has an Object request Broker (may be
> SkunkWeb has it, too). 

Depends on how you define it, but in short, yes you can call components
from outside of the SkunkWeb server if you configure it to allow it.

> ZServer is a multiprotocol server that already
> understands HTTP, PCGI, FastCGI, FTP, WebDAV protocols;

SkunkWeb understands HTTP and aecgi (similar, but different to the
protocol that the Apache Java Servlet engine speaks).  

One could argue that WebDAV and FTP are absolutely necessary for Zope
because of the fact that the templates don't reside in a filesystem.
With SkunkWeb, you use Apache/mod_dav for WebDAV and whatever FTP
server for FTP.

> it is modular,
> there is, for example, module for HTTPS protocol. 

Admittedly, SkunkWeb only supports SSL through Apache/mod_ssl right
now.

> There are many Database
> Adapters for relational databases: MySQL, PostgreSQL, Oracle, Informix,
> Interbase, Sybase, ODBC. 

SkunkWeb has support right now for Oracle, PostgreSQL and MySQL.
Others are definitely possible, I just don't have access to them at
this point.

> Security integrated into Zope, and is really very
> well implemented. 

Being somewhat of a security weenie, I'll leave very much well alone
on this one.

> Acquisition allows you to do very powerful object
> publishing.

A feature which works well for experienced programmers, but not all
people who build web pages (notably designers and HTML jockeys) are,
and you always have to keep them in mind.  It can cause a bit of head
explosion for a while until they get used to it.  One could argue
whether the power is worth the complexity.

> ZClasses are for simple programming. 

Wouldn't it seem reasonable for simple programming not to require a
class?

> ZCatalog - integrated
> search system.

Assuming you store everything in the ZODB that is...

> ZEO - clustering component. 

One could argue that if you store your data in a more conventional
database and your files in a filesystem, that ZEO just doesn't seem
that big of a deal.

Also, SkunkWeb can share it's cache between machines if the cache
lives on NFS or other shared filesystem (and of course, recover
gracefully if the filesystem goes away).

> Many good Products. 

Can't argue there.

> A lot of
> good documentation.

Depends on who you ask.

Cheers,
Drew
-- 
print(lambda(m,d,y):['Sun','Mon','Tues','Wednes','Thurs','Fri','Satur'
][(lambda(m,d,y):(23*m/9+d+4+y/4-y/100+y/400)%7)(m<3and(m,d+y,y-1)or(
m,d+(y-2),y))])(map(int,raw_input('mm/dd/yyyy>').split('/')))+'day'