mail.w-nz.com

I’ve successfully installed vpopmail, qmail and courier today, after some hours of work on this server.
From now on you can send e-mail again to @w-nz.com adresses, which won’t end up in /dev/null. (like bas.westerbaan@~)

To the users of the server: if you want an email-address, mail me.

While testing my smtp server whether it would receive incoming email properly I was harshly confirmed by it being spam instead of my test mail entering my mailbox first:

Hello Spam!
It’s pretty funny to see spam junk in an ancient text-mode mailing program.

If anyone experiences problems with any application not mailing you any verification as it should, please email me. It could very possibly be that the qmail-send isn’t configured properly to allow unauthorized local mails.

Update: More good news, the amount of RAM on my virtual server has increased to 120MB! Which means that my server won’t be swapping instead of working all the time anymore.

Server transfer: downtime

I will soon own a quite cheap virtual server (by greenT, great company) which will give me way more flexibility than the current shared server account on which w-nz.com is located.

I’ll transfer my current site to the new virtual server from the current shared server account (w-nz.com; xr12.com; intrepidsoft.net).

In the worst case this could result in domain problems, transfer problems and lack of time to get it done and therefore a lot of downtime.

So when w-nz.com is down please be patient and if you want to email me use bas.westerbaan@gmail.com instead of my @w-nz.com email addresses.

Modular Server

(Understanding URIs)

“A common mistake, responsible for many HTTP implementations problems, is to think this is equivalent to a filename within a computer system. This is wrong. URIs have, conceptually, nothing to do with a file system. One should remember that at all times when dealing with the World Wide Web.”

So why do most HTTP servers still heavily rely on the filesystem dictating URL’s?

This not only tends to create Uncool URI’s, but also makes it seem logical for filebased dynamic content (more on that in my previous post).

A http server, actually every server should be nothing more then a wrapper for modules which handle requests of clients.

The server would only limit itself to a very selected amount of functions

  • Handling connections
  • Exposing an API for the protocol which the modules can us
  • Hosting modules

On startup the server loads modules and binds them to certain URL. Modules remain persistant in the memory and are just signalled a request is made passing the module an API to handle the request.

I’ll be busy exploring the posibilities to implement this.. there will be more about this.