Slashdot Mirror

In the world of Open Source, I would also like to see the sum total of Open Source web servers VS. IIS:

Nginx http://www.nginx.org/ ( really popular and at least this is in one of the graphs)
Lighttpd http://www.lighttpd.net/ (personally, I have found many reasons use this one in the past and I'm sure I will again)
Cherokee http://www.cherokee-project.co... (yet to explore past a basic setup)
Roxen Webserver http://www.roxen.com/products/... (Still need to take for a spin)

And then special purpose web servers.

HTTP Explorer http://http-explorer.sourcefor...
HFS HTTP File Server http://www.rejetto.com/hfs/

At least that's all I can think of. Anybody else?
I know some of these take up negligible market share, but I would still like to see their market share lumped together.

Hey, if google wanted to hire me, I'd totally take it.

Here's a bit of advice from someone who's been down that road, Junior:

Steer clear -- well clear -- of any organization that, as part of their screening process, asks you about the details of an obscure (and obsolete) RFC.

I was invited for another interview, but I politely declined. I've never looked back.

Well, maybe Apache does not have these, but other OSS web servers have. Eg if I understand the feature list correctly Roxen WebServer does have at least hot-swappable modules.

The problem is when standards are violated, which most often is a Windows problem. Most of the problems with Samba (and Samba-NG) are caused by Microsoft, for example. Microsoft's current tiff with the EU, over not wanting to release network protocols to Open Source projects, isn't helping Microsoft's case any.

However, not all problems are due to Microsoft. The administration is, as has been noted by others, often to blame. Roxen, a rival Open Source webserver that supported SSL before Apache, is available for Windows 2000/XP. Apache 2.0.x has often been criticised for problems (causing many to stick with the 1.x branch) so if it's a problem with 2.0 which could be avoided with 1.x then they've only themselves to blame.

(And if they're using the Apache 2.1 tree for a production system, they're idiots.)

So there are solutions, you just need to look for them. Going with all-Windows, however, would not be one of them, unless you're working with a uniform Windows release, not just Windows. NEVER mix NT domains with Windows 200x domains, for example.

Also, because of architectural differences, drivers available for the XP core won't necessarily have counterparts in the 200x core. They may, but you cannot assume that. I believe it's XP that has IPv6 support, 2000 doesn't. That's just one example. The problem will likely worsen with Vista, particularly for graphics, as they've totally redesigned how graphics work. (Off-loading is a GOOD thing, but Microsoft has stated it doesn't document internal APIs, so compatibility isn't guaranteed.)

High-level software faces similar problems, where the API it is based on has been broken, so applications may or may not run correctly on different versions of Windows. DirectX software often faces this problem, as DirectX is not evenly maintained across code bases.

I would also avoid .Net like the plague. It is a solution looking for a problem and is the "in thing" for people to code to for now. But, then, so was Java. And CORBA. And RPC. And DCL. And, in earlier times, X.25, X.400 and X.500. Generally, for maintainability and longevity, you want to use as few layers as you can physically get away with. This is why virtually no Operating System in the world implements all 7 OSI layers and why layers generally bleed into one another.

All-*nix solutions are, as I've said, often better but they still have their problems. Binary-only software should work just fine on any *nix platform, because you can always ship the necessary libraries (and install whatever is not already there locally, using LD_LIBRARY_PATH to point to the local version), or you can statically compile.

In practice, *nix programmers are just as liable to take shortcuts that damage compatibility or which are dubious practices. It is unclear who has done so, in the arguments beween Hans Reiser and the other Linux kernel developers, but I can guarantee a fully-functional Reiser4 would be in the kernel by now if everyone was following good practices.

DSM (Distributed Shared Memory) should be independent of how processes are shared, but OpenMOSIX' DSM is unlikely to be folded into the main kernel any time soon.

Applications are no better - you can't guarantee Oracle or DB/2 running on Linux platforms they weren't compiled for, even though (as I've said - and was saying when Oracle first mooted a Linux port!) such incompatibilities are optional and the choice of the developer(s) involved.

It is almost impossible to design a system that prevents crappy programming (by later system developers or by application developers), and where attempts to do this HAVE been made, nobody wants to use the systems.

Ok,

Weighing in with my two cents worth, for what it's worth, I'd like to brain dump what I would consider worth while options for your needs. All of these are solutions I either have used in the past successfully, or am currently using for various purposes. So bear in mind that this is not just the causal musings of a thread cruiser, but actual tried and proven solutions ;-)

First some basic assumptions:

1) You want to run some form of Unix or Unix like system ( i.e. Linux ) - you've noted you currently use your Apple PowerBook laptop, so one has to assume you're running Mac OS X 10.x.x natively ( more power to you ).

2) You want complete control over the system including "root" access 24/7 - this is of course the whole point of having your own system, you can beat it up, break it, rebuild it, and all that jazz.

3) The system should be able to be run remotely, even if just headless on your LAN, or perhaps more ideally remotely from some external 3rd party in a hosted solution so you don't end up having to host it behind your link at home ( also making it easier for you to provide access to other parties should you want to either share it with friends and family or if you just want to make it world visible for whatever reason - i.e. your own mail and web server et al ).

4) You want an "always on" solution, so this should be something that, as you state, should not suck too much juice power wise, is able to be built with a "standard build" style hardened platform, which in the case of power loss would ideally recover nicely, quickly, and be back on line ( I'll touch on this later as standard builds are going to make your life so much simpler and fun ).

5) The performance of the system ideally should be such that it will cope with the key elements you've noted in your post, such as:

a) remote access such as remote sessions via SSH won't kill the system

b) able to run a web server such as:

thttpd: http://www.acme.com/software/thttpd/
Apache: http://www.apache.org/
mathopd: http://mathop.diva.nl/
Roxen: http://www.roxen.com/
Boa: http://www.boa.org/
Jigsaw: http://www.w3.org/Jigsaw/ ( written in Java )
Acme.Serve: http://www.acme.com/java/software/Acme.Serve.Serve .html ( written in Java )
CERN: http://www.w3.org/hypertext/WWW/Daemon/Status.html
NCSA: http://hoohoo.ncsa.uiuc.edu/
Netscape FastTrack: http://home.netscape.com/ ( not sure if it's still available )
Netscape Enterprise: http://home.netscape.com/ ( not sure if it's still available )
Zeus: http://www.zeus.co.uk/

source: http://www.acme.com

The little known Roxen webserver (http://www.roxen.com/) has an excellent CMS. It uses CVS to manage workflow and content revision, showing only the trunk-head to regular site visitors. It uses server-side XSLT and Roxen's 10 year mature caching systems. Roxen has had built-in browser-based "GUI" administration and configuration since it was called Spinner back in the early days of the web. It's only downfall has been that it was written in "uLPC", the language of MUDs, rather than pure "C".

The webserver (platform) is free/OpenSource (http://download.roxen.com/ and includes one of the easiest web-scripting languages around, RXML. The CMS is freely available but costs for commercial use.

The little known Roxen webserver (http://www.roxen.com/) has an excellent CMS. It uses CVS to manage workflow and content revision, showing only the trunk-head to regular site visitors. It uses server-side XSLT and Roxen's 10 year mature caching systems. Roxen has had built-in browser-based "GUI" administration and configuration since it was called Spinner back in the early days of the web. It's only downfall has been that it was written in "uLPC", the language of MUDs, rather than pure "C".

The webserver (platform) is free/OpenSource (http://download.roxen.com/ and includes one of the easiest web-scripting languages around, RXML. The CMS is freely available but costs for commercial use.

they want to make sure everyone is nice and compliant about upgrading when they decide to take httpd over to java like all the other java kool-aid they are selling --- Maven is Jonestown, lets all program in XML because its standard! Cultures breakdown when there is too little disent and questioning of authority, the apache foundtion is headed in that direction.

Lets move on, SOA and all that, most people don't need any of this mod_* crap and could use:
thttpd he has other servers there, too and http_load.
lighttpd I'm moving to this sweet little server for most apps and the home site runs ea php and ruby on rails
AOLServer like OpenACS runs on
Boa
fnord from our boy who did the (in)famous benchmarks
Cherokee I root for this one for some reason.
gatling
cthulhu
yaws in erlang, should support more simul. connections than the unlying OS can support.
dhttpd
Litespeed check out their php benchmarks
thy
roxen
mini-httpd never tried this one
xitami I have a intranet server running for 5 yrs (without upgrading xitami) on xitami Solaris, simple, small, easy to admin, never dies max uptime was 1000 days+.
eddiefor complex load bal and geographic distribution
hiawatha

And for the love of god, please at least design your sites to get their images from images.mysite.com if possible so that you can use a non-bloatware web server to server the images, reserving horsepower on your apache server for stuff that actually _requires_ some features of apache.

http://www.hcsw.org/awhttpd/ updated on 12-06-2004
http://www.norz.org/zawhttpd.html
http://cr.yp.to/publicfile.html

RXML

This isn't how it would work. When a client resolves a domain name, it would provide a domain name and "use ID" and would get, in return, an IP address and port and would go directly to the IP/port.

There are problems with using site-variable port numbers: it makes identifying traffic types a little tricky, having implications for e.g. traffic prioritisation, blocking malicious/unwanted traffic. As such it's probably more useful on a network within one administrative domain than on the internet. There's no corresponding method for looking up service types given a port number and IP address (e.g. additional records to in-addr.arpa) to help out, possibly because it would be rather difficult to place any degree of trust in that data anyway: you can't really have an unknown DNS server controlling your firewall policy. This is a bit of a different thing than MX records, where port numbers can't be defined.

It wouldn't be any more difficult than what all mail clients have to do right now to determine the MX record for a domain name. All software would have to provide that "use ID" and then connect to an IP/port, rather than how things are done now where there is no "use ID" and the port is assumed. It wouldn't burden anyone very much.

A web browser vendor is unlikely to be particularly happy to add and default-enable a feature that adds to the time taken to resolve the majority of names - but realistically, you won't have very high takeup on the server side until most clients threaten not to connect unless it's done. For newer protocols it's simpler, since there often need be no fallback to A record, and indeed SRV records are being used on some newer protocols. Still, the traffic identification problem is still there.

Adding this to HTTP is a bit different than the case with adding MX to email: many more people will notice the increased time to resolve the name. With email, the delay is in the background, after the message has left the end-user's mail client and enters the transport system: it's almost invisible. With interactive requests such as HTTP, any delay is immediately obvious.

Since it doesn't really buy you anything you don't get from an address-translating device on the IP address of example.com, and given the complexities and problems it adds, who's going to use it?

Hmm - I'd have to say that using RXML's emit and tablify tags together is about the easiest way possible to quickly get data from a database into a decent looking form for an end user.

And considering that accessing a form value or a cookie is as easy as &form.varname; or &cookie.cookiename;, hooking cookies and form variables into the page is about as easy as it can get.

Hmm - I'd have to say that using RXML's emit and tablify tags together is about the easiest way possible to quickly get data from a database into a decent looking form for an end user.

And considering that accessing a form value or a cookie is as easy as &form.varname; or &cookie.cookiename;, hooking cookies and form variables into the page is about as easy as it can get.

Hmm - I'd have to say that using RXML's emit and tablify tags together is about the easiest way possible to quickly get data from a database into a decent looking form for an end user.

And considering that accessing a form value or a cookie is as easy as &form.varname; or &cookie.cookiename;, hooking cookies and form variables into the page is about as easy as it can get.

Pike is a dynamic programming language with a syntax similar to Java and C. It is simple to learn, does not require long compilation passes and has powerful built-in data types allowing simple and really fast data manipulation.

Well, Roxen has its GPL'ed webserver, and it's a very good one.

I like Apache and everything, but it's good to know there are alternatives.

Well, Roxen has its GPL'ed webserver, and it's a very good one.

I like Apache and everything, but it's good to know there are alternatives.

How many of those operating systems use Apache?

You mean including Windows, all of them can, but there are fare more webservers available for Unix like systems than there are for Windows. Thttpd, wn, Thy, Roxen, Fnord, Dhttpd, Caudium, Bozotic, Boa, and AOLserver are all available in Debian in addition to Apache. Most of these are IPv6, ssl/tls, and cgi capable. They all have their strengths, and they all are being actively maintained. Most of these will operate as a drop-in replacement for Apache for most sites.

You are correct that most of the web servers on the net are Apache installations of one type or another. Most sites do not need or use all of the features that Apache offers, but install Apache anyway. Sound familiar? They are still thinking in traditional market terms, instead of looking at what is available to them. They treating Unix as if it were Windows, but if an cross-platform Apache-specific worm were to affect them adversely, there will be alternatives available to them that they would not have on Windows.

The point is that Unix like operating systems offer greater variety of more services in more implementations than Windows does or ever will. There is more room for fault tolerance, more methods available, and more capability to find new solutions to new and old problems (including security) in Free Software than any company or group of companies is capable of providing.

The Lizard.

MySQL.

GNU Project.

Slackware Linux.

Mepis Linux.

K Desktop Environment.

Gnome.

Perl.

Apache WebServer.

Roxen WebServer (very intuitive, and GPL!).

Phew!! And that's a short list!! There are hundreds and hundreds and hundreds of open source, free-for-all applications.... so many it's almost absurd not to use them!! Go ahead and get them!

Or use the webserver, Roxen?

The only forks I've seen in major projects have been when a new version has been released but the old version has continued to have occasional maintenance patches released.

Depends what you mean by "major" (are you talking popularity, or size?)

The web server I use forked a few years ago - it's not as popular as Apache, but is just as much a "major" project (as far as lines of code.) I use it over Apache for a number of reasons (including speed, flexibility, and ease of development.)

The fork happened for a number of reasons, but the straw that broke the camel's back was a major release which broke backwards-compatability.

If the fork had not happened, I would have been stuck either with a dead project (no upgrades, not even bug fixes) or having to waste hundreds of hours re-learning the software and re-writing sites.

The fork gave me an upgrade path, as well as better support.

FYI, here are the (4) proposals that I know about:

RMX proposal (Mike Rubel's page) - Last published draft (Oct 2003).

DMP - No change or update since this was posted back in August 2003.

DRIP - Published July 2003 by Raymond S Brand and Laurence Sherzer.

SMTP+SPF - Last updated Dec 1 2003. Last RFC draft is Oct 2003.

Anyone have any inside track on where these proposals stand?

Nope - ofdoom.com runs FreeBSD 4.x / Roxen 3.4.94-cvs / Pike 7.4 release 28.

The central idea behind reverse-DNS/MX proposals is to answer the following 2 questions:

1. Does a particular domain have a list of authorized IP addresses that are allowed to send out e-mail on behalf of the domain?

2. Is the IP address of the mail server that is attempting to talk to me on that authorized list?

The devil is, of course, in the details/implementation. (Can we do it without breaking older versions of BIND? What attacks is it suspectible to?)

Here's the (4) proposals that I know about (since I just went looking yesterday):

RMX proposal - No news on Mike Rubel's page since June 2003. Not much on the official home page either. The last published draft is June 2003.

DMP - Last IETF draft published Aug 2003 and expires at the end of Sep 2003. However, version 5 of the document has not yet been posted and the author(s) does not have seem to have a central site to check for news.

DRIP - Last draft was published July 2003, expires Dec 2003. I don't see anywhere a central home page to check for news.

SMTP+SPF - Last update was mid-July 2003. I'm not sure if there is an IETF draft being floated or not.

I've been looking at a couple of different techniques over the past year or so. They are closely tied into the Roxen Webserver, and probably won't work with Caudium, or any other webserver.

The first technique I used (described here) was a simple RXML macro, that defined a tag called <cloak>. It would check to see if the client was on a list of known robots. If the client was a robot, a graphic version of the email address would be returned. If the client looked like a normal browser, then the address would be entity encoded, and returned as a mailto link.

Shortly after I set that up, I realized that entity encoding was pretty much useless - that if a web browser can figure out the address, so can a spam bot.

My second attempt appears to be working well. I wrote a Roxen module called mailcloak which takes addresses, and replaces them with a graphic link to a dynamically generated form to send an email to that address.

As an example, the code <mailcloak> maileater@ofdoom.com</mailcloak> would be replaced with a graphical version of the address maileater@ofdoom.com and a link to this page.

It also has support for finding and cloaking bare addresses in pages, and I'll probably add support for rewriting mailto tags sometime in the next few weeks.

Here's the current list of the 4 proposals that I know about.

RMX proposal

SMTP+SPF proposal

DMP proposal

DRIP proposal

All (4) of those perform pretty much identically, with various trade-offs. The 2 key questions that an SMTP server needs answered are:

- does this domain have reverse-MX information?

- is the origin IP address authorized to send e-mail for the purported origin domain?

And possibly a 3rd question for farther down the road (although this is possibly over-kill):

- has the e-mail been properly signed by the sender of the e-mail

IIRC, NSLookups fail because it makes the assumption that everyone is in control of their reverse IP info and that people don't service multiple domains from a single IP address.

Or one of the other proposals (personaly, as a mail admin, I don't care which of the proposals make it so long as I can stop having my domain name forged onto e-mails that we didn't send):

RMX proposal

DMP proposal

DRIP proposal

Unfortunately, it'll probably be 2-3 years until the standard organizations get off their duffs and pass something.

There are currently (at least) 4 different proposals that I know about to end the process of domain spoofing (which is part of the battle).

RMX proposal

SMTP+SPF proposal

DMP proposal

DRIP proposal

1. If a mail server does not relay mail, it is rude for a test to result in mail to the administrators of that server
2. It is possible for the username they use in their test to actually deliver mail to a real user. I consider it as bad as spamming if their test drops dozens of messages in the account of an innocent user with no idea of what is happening, or control over the mail server.

Well, apache is not the be-all end-all of webserving. There are lots of webservers available for the *nix platform that are not based on or related to apache. One notable exception is roxen, although the development activity is a bit shady at the moment. Check freshmeat for more webservers. There are many.

I'm just wondering if the patent being granted is someone hinged on Interwoven's claim to be the first to do version control for 'web assets' (ie, HTML, images) as opposed to source code.

Even if they got the patent for this, it's still nothing new. Roxen has been doing this since (at least) 1997.

Pike does this to a fairly decent extent. Its more or less C as a scripting language with objects(I avoid saying C++ because of syntactical ugliness in the connotation). I've used it for a few small things, I haven't had the time to really explore the language in depth, but i have a hell of an XML-RPC server running in it.

On systems with IA32, SPARC or PPC32 processors Pike can use native machine code as byte code. This byte code can then be executed directly outside the virtual machine and give a ~30% performance boost compared to the old byte code.

On systems with IA32, SPARC or PPC32 processors Pike can use native machine code as byte code. This byte code can then be executed directly outside the virtual machine and give a ~30% performance boost compared to the old byte code.

There's an old RFC that discusses this very thing: rfc2116

It's from '96, so it's probably incredibly out of date, but it might be a good place to start?

It sounds to me that either Roxen or Caudium might meet your needs.

Both are multithreaded web servers, which are very good at producing dynamic content.
They have a very nice macro language built in (RXML) and support scripts written in the language Pike (which both servers are written in as well). Both also support embedded perl scripts, as well as java servlets, and fastcgi scripts. It also has very good database support, and support for dynamic image generation.

I haven't used Caudium myself - it is a fork of the Roxen 1.3 codebase, and I had already started using the new 2.x features before the fork happened. It is GPLed, and is available here

Roxen is available in two forms, a free GPLed version (available here) and a commercial version which includes content management features (Demo available here).

The new versions of Roxen are bundled with a MySQL install which the server uses for storing configuration data, caching generated images and pike/rxml pcode, and for storing internally managed user databases. It also works well with PostgreSQL as an external database.

Php support in roxen is a little tricky. Recent versions of PHP can be compiled into a module that can be merged into pike, allowing both Roxen and Caudium to execute PHP scripts inside of the multithreaded main process. This is still buggy under Roxen, but I understand that it works well under Caudium. Personally, I compiled php as a fastcgi, and used Roxen's fastcgi module.

It sounds to me that either Roxen or Caudium might meet your needs.

Both are multithreaded web servers, which are very good at producing dynamic content.
They have a very nice macro language built in (RXML) and support scripts written in the language Pike (which both servers are written in as well). Both also support embedded perl scripts, as well as java servlets, and fastcgi scripts. It also has very good database support, and support for dynamic image generation.

I haven't used Caudium myself - it is a fork of the Roxen 1.3 codebase, and I had already started using the new 2.x features before the fork happened. It is GPLed, and is available here

Roxen is available in two forms, a free GPLed version (available here) and a commercial version which includes content management features (Demo available here).

The new versions of Roxen are bundled with a MySQL install which the server uses for storing configuration data, caching generated images and pike/rxml pcode, and for storing internally managed user databases. It also works well with PostgreSQL as an external database.

Php support in roxen is a little tricky. Recent versions of PHP can be compiled into a module that can be merged into pike, allowing both Roxen and Caudium to execute PHP scripts inside of the multithreaded main process. This is still buggy under Roxen, but I understand that it works well under Caudium. Personally, I compiled php as a fastcgi, and used Roxen's fastcgi module.

It sounds to me that either Roxen or Caudium might meet your needs.

Both are multithreaded web servers, which are very good at producing dynamic content.
They have a very nice macro language built in (RXML) and support scripts written in the language Pike (which both servers are written in as well). Both also support embedded perl scripts, as well as java servlets, and fastcgi scripts. It also has very good database support, and support for dynamic image generation.

I haven't used Caudium myself - it is a fork of the Roxen 1.3 codebase, and I had already started using the new 2.x features before the fork happened. It is GPLed, and is available here

Roxen is available in two forms, a free GPLed version (available here) and a commercial version which includes content management features (Demo available here).

The new versions of Roxen are bundled with a MySQL install which the server uses for storing configuration data, caching generated images and pike/rxml pcode, and for storing internally managed user databases. It also works well with PostgreSQL as an external database.

Php support in roxen is a little tricky. Recent versions of PHP can be compiled into a module that can be merged into pike, allowing both Roxen and Caudium to execute PHP scripts inside of the multithreaded main process. This is still buggy under Roxen, but I understand that it works well under Caudium. Personally, I compiled php as a fastcgi, and used Roxen's fastcgi module.

It sounds to me that either Roxen or Caudium might meet your needs.

Both are multithreaded web servers, which are very good at producing dynamic content.
They have a very nice macro language built in (RXML) and support scripts written in the language Pike (which both servers are written in as well). Both also support embedded perl scripts, as well as java servlets, and fastcgi scripts. It also has very good database support, and support for dynamic image generation.

I haven't used Caudium myself - it is a fork of the Roxen 1.3 codebase, and I had already started using the new 2.x features before the fork happened. It is GPLed, and is available here

Roxen is available in two forms, a free GPLed version (available here) and a commercial version which includes content management features (Demo available here).

The new versions of Roxen are bundled with a MySQL install which the server uses for storing configuration data, caching generated images and pike/rxml pcode, and for storing internally managed user databases. It also works well with PostgreSQL as an external database.

Php support in roxen is a little tricky. Recent versions of PHP can be compiled into a module that can be merged into pike, allowing both Roxen and Caudium to execute PHP scripts inside of the multithreaded main process. This is still buggy under Roxen, but I understand that it works well under Caudium. Personally, I compiled php as a fastcgi, and used Roxen's fastcgi module.

You have a point. But it still has issues when you are a U.S. citizen or not... At least, when I was downloading the roxen webserver (which is very nice btw, give it a whirl when you have a chance) they asked me if I was a U.S. citizen or not, regarding the LZW compression stuff.

... Cold Fusion... CFML...

Great stuff for development. Incredibly easy, flexible (just gotta learn the internals), and source available.

I've done a lot of web development, in a variety of languages. I've been working in the ISP sector since 1993 - I wrote tools and utils for AmiTCP in-between increasing the dogearedness of my pink-cover first version camel book.

PHP suffers from the same issues as JSP when it comes to building webapps and toys. It's also not really the most efficient system around either.

Much as I love Perl, and have always enjoyed knocking out CGI systems - including one of the first "fansite"s which offered people free custom emails and URLs (warbirds.org), and I've had lots of fun with PHP, I have personally found Roxens built in RXML mark-up language to be one of the most efficient systems for developing web applications in terms of design, implementation and operation.

Roxen was born "Spinner" back around, if not before. In all those years since, I've yet to find a good or compelling reason to use Apache, Perl or PHP instead of Roxen beyond the head-count factor. The Roxen developers make their money through 'value adding' their open source webserver platform, but never really tried to market themselves.

There is no need for a web server to be running anything [on an open port] other than Apache.

What about Roxen? What about AOLserver? What about the hypothetical future complete rewrite of IIS? And what about Other?

Roxen has a nice htmlized version of rfc 2321 and most other rfcs as well.

I use a little trick that combines both of those techniques.
It's a little block of RXML that defines a tag called cloak. You use it like this:

<cloak email='foo@pathwalker.org' />

If Roxen determines that the client is a robot, or it can't identify what the client is, then they get a graphic.

If they are detected as a normal webbrowser, then they get a partially entity encoded address.

If anyone uses Roxen as their server it might be of some use.

I use a little trick that combines both of those techniques.
It's a little block of RXML that defines a tag called cloak. You use it like this:

<cloak email='foo@pathwalker.org' />

If Roxen determines that the client is a robot, or it can't identify what the client is, then they get a graphic.

If they are detected as a normal webbrowser, then they get a partially entity encoded address.

If anyone uses Roxen as their server it might be of some use.

I use a little trick that combines both of those techniques.
It's a little block of RXML that defines a tag called cloak. You use it like this:

<cloak email='foo@pathwalker.org' />

If Roxen determines that the client is a robot, or it can't identify what the client is, then they get a graphic.

If they are detected as a normal webbrowser, then they get a partially entity encoded address.

If anyone uses Roxen as their server it might be of some use.

Better yet, store the information in memory, and display the contents of the memory variable. Refresh the variable every ten or fifteen minutes, or simply deallocate it if nobody's looked at it for ten or fifteen minutes. Still dynamic enough, and your database will thank you

Congratulations, you've just reinvented Roxen's Cache Tag.

In Roxen, wrapping that pesky block of CPU/database intensive code in <cache minutes='15' > </cache> tags would have done pretty much what you describe, without any extra coding...

Better yet, store the information in memory, and display the contents of the memory variable. Refresh the variable every ten or fifteen minutes, or simply deallocate it if nobody's looked at it for ten or fifteen minutes. Still dynamic enough, and your database will thank you

Congratulations, you've just reinvented Roxen's Cache Tag.

In Roxen, wrapping that pesky block of CPU/database intensive code in <cache minutes='15' > </cache> tags would have done pretty much what you describe, without any extra coding...

I've managed Apache at work, and Roxen at home. I still can't say whether one is better than the other, but I do like those RXML tags, so I'm sticking with Roxen for now.

I'll stick to Pike - one of the best languages I've ever used..