[ANN] SkunkWeb 3.0 Released!

[Drew Csillag]

On Fri, Aug 24, 2001 at 01:42:47PM -0700, Paul Rubin wrote:
> Drew Csillag <drew_csillag at geocities.com> writes:
> > Mason and SkunkWeb compare rather well with each other, as they do tend 
> > to attack the web serving problem in similar ways.
> 
> Thanks... a few more questions...
> 
> Does SkunkWeb have any automatic workflow (content management) tools
> the way Mason does?

Currently not.  That is one area where we could definitely use some
help.  Right now, our content management system is CVS.  Though there
is a Service called pars, which you can make a content archive and have
SkunkWeb serve it directly from the archive file.

> >  * Mason and SkunkWeb have a similar approach to their templating languages,
> >    but I don't think you can reasonably extent Mason's whereby SkunkWeb's
> >    templating language was designed to be extendable.
> 
> Can you say why all those template tags are needed?  Do they get you
> something that a PHP-like approach doesn't?  PHP just has a <?php ... ?>
> tag and you replace the ... with PHP code.

Well the problem I've seen with ASP style templates (PHP included) is
that if you're working with people who don't know a whole lot about
coding and they want to change the layout, the can really botch the
template rather badly (one case that comes to mind is when a
translator translated the program code to Spanish).  With the tag
based things, the non-programmer type HTML people can edit the layout
without worrying about whether they got the code bits right, since the
code is in the tags.  I guess it's mainly an issue of the skill level
mix of the people who are going to be editing templates.

> >  * Mason and SkunkWeb both have HTML and data components.
> >
> >  * Mason and SkunkWeb both have a Request object (though SkunkWeb calls
> >    it CONNECTION).
> 
> OK
> 
> >  * Mason uses Perl, SkunkWeb uses Python.
> 
> Advantage SkunkWeb :-)
> 
> >  * Mason runs in-process with Apache (under mod_perl), SkunkWeb is
> >    it's own daemon (Apache talks to the daemon either by mod_skunkweb
> >    or by a CGI) and if you like, can serve HTTP itself directly.
> 
> OK... I prefer Skunkweb's approach as long as you don't have to fork
> new Skunkweb processes all the time.

SkunkWeb preforks a fixed number of processes that stick around for N
connections and then they commit suicide and are replaced by new
children.  You can set N to 0 and they will stay around indefinitely.
The main reason for this is if you construct a large result (say a few
megabytes), some operating systems (Solaris specifically has this
problem) don't reclaim the memory when it is free()d, so while this
memory will be reused, the excess is never actually given back to the
OS.  It's also a hedge agains a memory leak somewhere.

> >  * Caching.  Mason caches component output to DBM whereby SkunkWeb
> >    caches to disk files.  SkunkWeb's cache can be shared between
> >    machines as well as managed with filesystem tools.  SkunkWeb's
> >    caching interface is also a lot easier to use.
> 
> OK, but if you need a lot of caching, is that not a sign that the
> template engine is too slow?  

Actually no.  The database is often a bottleneck, so instead of
hitting the database for each request for which 99 out of a 100 times
will return the exact same result, you might say: "only hit it every
10 minutes".  OTOH, if you have a component that does some complex
computation, you might want to cache that.

> I'm even more scared of Zope.  I notice
> that www.zope.com says it's served by three separate machines
> connected by a load balancer.  I don't know how many visitors they get
> but it can't be nearly enough to need that much hardware under any
> reasonable page generating system.

I would have to agree that this seems a bit much.  I would think that
this may be due to their template rendering engine as it may have to
do with their template interpreter.  In SkunkWeb, the interpreter is
the Python interpreter (STML is compiled to Python source, and
subsequently to Python bytecode), so the there is no additional
interpreter overhead in SkunkWeb.  In the case that you want to see
what it generates, there is a utility in /usr/local/skunk/util called
vicache.py and you can see the Python code it generates (and edit it
too).

> I have no direct experience with any of these systems (Mason,
> SkunkWeb, Zope) though.  I read the Mason manual a few months ago and
> it seemed pretty good, though messy because it's Perl.  I've been
> using PHP and have been pretty impressed with it.  Can you add a
> SkunkWeb-PHP comparison to your FAQ?  I know that Mason (and SkunkWeb)
> do some things that PHP doesn't but I've forgotten what.

Sure.  I'll have to look more at PHP to answer this though, as it's
been a while since I looked at it.  I've also been thinking that a
PSP-style templating language would probably be a useful addition.
I've got one sorta written, I just need to clean it up and hook it
into the component rendering code.  Documentation for it might be nice
too :).

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'