SkunkWEB - smell the power!
about .
docs
download
mailing list
news
CVS
SkunkDAV
PyDO
who
+ -------------------------- +
| many thanks to SourceForge |
+ -------------------------- +
  1. Marcos Sánchez Provencio <rapto@arrakis.es> asked: I think that the closest project to skunkweb is webware. They seem to share objectives. Is it not possible to join them? What are the important differences between them?
  2. What's the difference between SkunkWeb and Zope?
  3. Paul Rubin <phr-n2001@nightsong.com> Asks: How does it compare to Mason?
  4. Paul Rubin <phr-n2001@nightsong.com> asks: Can you add a SkunkWeb-PHP comparison to your FAQ?
  5. Dave Swegen asks: Is there any way of allowing [some] files to be passed straight through, without compiling them?
  6. Dave Swegen asks: Is there any way for a pydcmp to get hold of the value of docroot? At the moment I'm having to hardcode the value in, which is somewhat ugly.
  7. How do you run CGIs and SkunkWeb with mod_skunkweb in the same server or virtual host? SkunkWebExclude doesn't work!
  8. My sw.conf file is unmanageable! Can I break it up into several files?
  9. How do I get at what in CGI land would be PATH_INFO?
1) Marcos Sánchez Provencio asked: I think that the closest project to skunkweb is webware. They seem to share objectives. Is it not possible to join them? What are the important differences between them?

Yes, they definitely do share objectives, but they differ in many ways as to the approach:

  • WebWare uses a threaded model. While in some ways makes things simpler, it makes many things more complicated. Also, because of the Python global interpreter lock, if you have more than 1 CPU, WebWare won't actually use very much, if any of the additional CPUs since only one thread can run at a time. SkunkWeb uses a forking process model, which makes resource sharing more complicated in certain circumstances, it will fully utilize all available processors, so SkunkWeb scales better. It also makes reliability simpler, since if you screw up in one process, it won't kill the whole server. OTOH, this makes it probably not run on Windows, but it may run under Windows with the Cygwin toolkit. Besides, windows has enough problems.
  • Caching. WebWare doesn't have any built in output cache mechanism.
  • Internationalization. I don't believe that WebWare has any builtin support for message catalogs and the like.
  • Web Components. SkunkWeb encourages the componentization of your web pages through caching and the like. It can also call components on other SkunkWeb servers if you set it up to do so.
I guess that's the short list. If you run latex on the SkunkIPC10.tex file (a paper I hope to give at the February conference) in the docs directory, that goes into a bit more detail.
2) What's the difference between SkunkWeb and Zope?

 Again, the SkunkWebIPC10.tex file in the docs directory goes into this stuff in greater detail.
3) Paul Rubin Asks: How does it compare to Mason?

Mason and SkunkWeb compare rather well with each other, as they do tend to attack the web serving problem in similar ways

  • Mason and SkunkWeb have a similar approach to their templating languages, but I don't think you can reasonably extend Mason's whereby SkunkWeb's templating language was designed to be extendable.
  • Mason and SkunkWeb both have HTML and data components.
  • Mason and SkunkWeb both have a Request object (though SkunkWeb calls it CONNECTION).
  • Mason uses Perl, SkunkWeb uses Python.
  • 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. Mason's approach can easily use more memory and database resources that the standalone daemon model if you are talking to slow web connections (which you generally are) since the time it takes to send the page is much more than it takes to render the page. In this case, you have a bunch of processes with Mason in memory and database connections open that are sitting idle waiting for the client to get the data, whereby with SkunkWeb, as soon as Apache gets the response back from SkunkWeb, the SkunkWeb daemon can start handling another request while the Apache process goes about sending the page back to the slow client. As an example, with SkunkWeb, you may have 100 Apache processes (not even necessarily on the same machine mind you) using only maybe 30 SkunkWeb processes. The other thing, since Apache's process pool grows and shrinks over time, you a) have less control over memory utilization, and b) you tend to reconnect to the database more frequently.
  • It doesn't appear that you can make custom url schemes with Mason without writing an Apache module to do it. In SkunkWeb, you can write a Service which does it. As an example, for my current employer, we have a url translation scheme which translates urls to and from Spanish and Portugese.
  • Internationalization. Mason appears not to have any builtin internationalization features. SkunkWeb has message catalogs.
  • 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.
  • Caching again. Since you can't get at the compiled representation of Perl code, you can't cache the compiled forms of things in Mason. In SkunkWeb, the templating language is compiled down to Python bytecode and cached to disk. Compiled forms of Python components and message catalogs are also cached to disk. The compile cache can also be additionaly stored in memory (as a read-through, write-through cache).
4) Paul Rubin asks: Can you add a SkunkWeb-PHP comparison to your FAQ?

  • PHP has it's own language, whereby SkunkWeb uses Python
  • PHP runs under mod_php (see the 5th bullet point for Mason).
  • PHP's database connections are not automatically rolled back at the end of a page.
  • PHP doesn't appear to have any builtin caching facilities except via user sessions.
  • It doesn't appear that you can make custom url schemes with PHP without writing an Apache module (or mod_rewrite) to do it. In SkunkWeb, you can write a Service which does it. As an example, for one of my previous employers, we have a url translation scheme which translates urls to and from Spanish and Portugese.
  • Internationalization. PHP appears not to have any builtin internationalization features. SkunkWeb has message catalogs.
  • PHP only supports one kind of page language whereby SkunkWeb currently supports two (Python and STML) and could support more (an ASP-style templating language comes to mind).
  • PHP, the language has general issues. Specifically, variable scope. There is no concept of modules. Everything at the top level in files is shared for all things you include. Python also has a much larger selection of modules either from the standard distribution, or available on the Internet than PHP, so you're less likely to have to write many things yourself.
5) Dave Swegen asks: Is there any way of allowing [some] files to be passed straight through, without compiling them?

One solution is a scoping directive in sw.conf (or in another file which you include into sw.conf through sw.conf's Include directive): 

Scope(Location("/nointerp.html", interpretMimeTypes=[]))
Where /nointerp.html is a document (or a directory name, whatever) you don't want interpreted. You could do this for an entire tree if you wanted also. If you are using Apache, the SkunkWebExcludeDocs directive can also be used to make Apache serve a tree of documents with its default handler.
6) Dave Swegen wrote: Is there any way for a pydcmp to get hold of the value of docroot? At the moment I'm having to hardcode the value in, which is somewhat ugly.

Sure. from SkunkWeb import Configuration doSomethingWith(Configuration.documentRoot) The Configuration object is generally speaking a treasure trove of such information. Be aware that it is a "scopeable" object, meaning that it can be configured to return different values for different variables depending on the request; the documentRoot, for instance, may not always be the same, so you wouldn't want to cache any component whose output is dependent on an internally-accessed Configuration variable that may be scoped. It is safer, therefore, to pass in the value of a Configuration variable as an argument to the component.

7)How do you run CGIs and SkunkWeb with mod_skunkweb in the same server or virtual host? SkunkWebExclude doesn't work!

If you set the skunkweb-handler for the root directory / and want /cgi-bin/ to serve cgi's as normal (meaning most likely that you have the directive 

ScriptAlias /cgi-bin/ /usr/local/apache/cgi-bin/
or something like it, in httpd.conf), one might think that using mod_skunkweb's SkunkWebExclude directive (thus: SkunkWebExclude /cgi-bin/) might work. Unfortunately, this configuration results in the cgis being handled by the default handler, which is nasty. This, however, does the trick: 
<Location />
SetHandler skunkweb-handler
</Location>
<Location /cgi-bin/>
SetHandler cgi-script
</Location>
8)My sw.conf file is unmanageable! Can I break it up into several files?

Use the Include directive: 

# in sw.conf
Include("/usr/local/skunk/etc/vhosts.conf")
Include("/usr/local/skunk/etc/rewrite.conf") # etc.
9)How do I get at what in CGI land would be PATH_INFO?

Add the rewrite service to your sw.conf services listing and add this: 

rewriteRules=(r'(.*\..*?)(?P<pathinfo>/.*)', r'\1')
and a cgi argument (accessed via CONNECTION.args or <:args:>) named pathinfo will contain what you want.
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
(smell the power!)