kaare (663)

Perl Mail Server

I installed qpsmtpd (journal entry http://use.perl.org/~kaare/journal/37631) a while ago. It is fun, you can mess with separate bits and pieces the usual Perl way, and qpsmtpd has a very low ressource consumption on the system.

So, just a thought. Why not implement a full-feature mail system in Perl? At least it would be nice to know if all the different mail server elements exist in Perl.

A quick look turns up rather mixed. Perl email modules mostly look dead, but so did Qpsmtpd until I started looking.

SMTP ServerShort answer: Qpsmtpd

Local deliveryYou can manage your sieve scripts with Net::Sieve. Perhaps there could be a Qpsmtpd plugin for delivery using Sieve scripts.

MTAI only found Tipjar::MTA. Doesn't support ESMTP according to the POD. Doesn't seem to be actively developed. But then again, I saw a patch to Qpsmtpd supporting tipjar recently.

IMAP ServerNet::IMAP::Server

POP3 ServerPOP3 is not a necessity in my world, but I know people who still use it. I haven't found any (recently active) Perl POP3 Server yet.

Mail storageEmail::Store (and PostgreSQL)Even if it seems to be Abandonware like the rest of Perl Email Project (http://emailproject.perl.org/) (it hasn't been touched for the last two years), it has at leas the notion of headers, body, attachment et al. There's also a database backend, which is a nice touch. With a proper database you would avoid the problem that the server could choke after only a few thousand emails in a folder. Also you could use all of the advanced features of your database. Full text search, for example, if you use Postgres.

Mailing listsand more. I'm sure there are more modules you could fit into a mail server. I didn't find a ready-to-use mailing list implementation, but it wouldn't be too hard to make one from scratch or from already existing modules.

Why would you want an all-Perl Mail Server? Well, you don't necessarily. But it would be easy to plug in some module to process an email for whatever reason it could support your personal or professional needs. Perhaps you would like specialized statistics on your email storage or email usage? Mail archiving? Easy program / email interaction?

This was just a thought experiment. I do wonder what happened to the Perl Email Project, though.

Thursday October 09, 2008

02:56 PM

qpsmtpd

Recently I had to move my mail domains off an external server and on to my own. It was an old Courier-MTA based implementation, and while there was supposed to be some kind of spam control, it obviously didn't have much impact, giving me several hundreds unsolicited mails to remove every day.

Now, there are a lot of options when deciding what to do with your mail, but I decided to try out qpsmtpd, it being Perl based and me having heard good things about it from people i respect.

I installed it, looked around and wrote some plugins for my special purposes. There are several plugins included in the distribution, and while the API documentation isn't obvious to find, you can mostly guess what is going on from the plugin code. I wanted to keep some of my previous Courier implementation and user database, but opted for another MTA.

One of Qpsmtpd's claims to fame is that it will detect wrong connections and bad senders very early in the process. This means that the server will save a lot of CPU and disk power simply because the you will receive almost only the real emails, not spam.

My conclusion: Qpsmtpd is fun. It is completely plugin based, so it will handle you the transaction at various stages of the mail receipt process and lets you have a go at it without limiting you unnecessarily. You decide what to do with the connection, and where to put the message.

The fun thing about Qpsmtpd is that it seems to be a well kept secret. People don't talk out loud about it. There is almost no CPAN presence, and you have to search to find a hidden (but active) mailing list.

Thursday August 07, 2008

01:49 PM

Catalyst CRUD

Catalyst is great. Unless you want it to help you build simple applications. I'm not trying to take the wind out of claco's sails (http://use.perl.org/~jk2addict/journal/37068) but I do expect him to conclude that Catalyst lags in this area, compared to other popular frameworks.

Not that this conclusion is a revelation from God. There are a lot of different initiatives trying to fix one or the other problem or adding some feature to make it simpler to develop - either by easing the creation of repetitive tasks or removing some technical barrier.

I've started listing these projects here: http://dev.catalystframework.org/wiki/crud. Until now it's just a project list. But don't hold back, please add any information, technical tidbit or comparison. It's a wiki after all.

Thursday June 19, 2008

05:39 AM

Software announcements

Firefox 3 yesterday and OpenSUSE 11.0.(http://download.opensuse.org/distribution/11.0/iso/ for CD's, DVD's and Torrents) today. I guess I know what my internet connection is doing tonight.It seems that OS 11 has been anxiously awaited. OpenSUSE's homepage has been down for the better part of today. And as far as I can tell, the announcement isn't even official yet.

And yes, I consider OpenSUSE the best Linux distribution there is. And I hope that the positive reviews of alphas, betas and RC's will prove themselves justified.

Saturday June 14, 2008

10:02 AM

gvim as a Perl IDE

I've decided to polish my gvim installation in order to have a more IDE like environment. Initially I wanted to find a replacement, but after looking at a lot of alternatives (trying some), amongst them eclipse, Geary, Kdevelop, Komodo, and more, I dedided to give (g)vim another chance.

Now, I've had perl-support [1] installed for some time now, and I find it quite impressive. I admit not having used all the features of this comprehensive package, but I'll definitely try out more features in the future.

So, today I've installed omniperl [2]. It seems to sorta work, but well... I can't even get the textbook example to work

my $now = DateTime->now;$now->^X^O

shows nothing.

DateTime::^X^O does give me a long list, but DateTime->^X^O just gives me a "pattern not found" error.

I guess that regular use will show if this is a useful package. Next, I wanted to see PelySense in action, so I dug up one of Ovid's old posts [3]. After some fiddling with the details (seems that pp and pg clash with perl-support definitions) it also kinda works. I get documentation for some - put far from all - methods. Noticeably, it can't find any Catalyst or dbic POD.

Again, I might be able to find better ways to use these features, so I'll keep them around at least for some time. Now this seems to cover the basic capabilities listed in gabor's post [4] and then some, but I miss one of the more important IDE requirements, the concept of a project (keeping together a set of related files).Now one could argue that if you do a standard project, all you have to do is find the files in./lib, but I would like gvim to be smarter than that. And at least smarter than it is by default, listing all files in alphabetical order. I think I'll try out the vim project extension [5], unless someone warns me not to!Another more "projecty" way could be to use ack for searching through files. Guess I have to try out Ovid's ack integration sometime. Now if he just would release all his vim Perl enhancements in an easy to install way...;-)

A life detour

The background is that I've had some strange spells the past 7 or 8 months. Feelings of skin numbness moving around, primarily up and down arms, legs, head, in a random fashion for a while, ending in a major headache. Strange and worrying, so I went to my doctor who sent me to a neurologist who in turn sent me to the hospital for a MRI scan.

Well, that's enough for most people to worry about, but when I met for the screening interview there was a surprise waiting for me. The doctor was surprised that nobody har meassured my blood pressure before in the process. So she did. And she went for another machine because this one was obviously not working correct. And she scrapped the second one too and used old fashioned stethoscope. After a moment of confused thoughts she said "I have to admit you to the hospital. I can't let you go with this pressure level!"

A bit shaken now, I used the elevator to get to Floor 9 where they quickly registered the first measurement as 220 over 170. And I didn't have a clue, how does things like that happen?

OK, maybe I should have had a clue. After all I've had this headache since saturday, even for me a 4 day headache is not common.

The quickly following ECG diagram showed that my heart is OK, that I haven't had this level long enough to make any damage, and this was confirmed by some of the blood samples, telling that the kidneys are unaffected too. A lot more testing and measuring followed this, but no conclusion has been reached yet.

Now I'm home for the weekend, but next week will bring more tests. Kidneys, eyes, perhaps even the MRI scan that was the original reason for the hospital visit, some of it _has to_ show why my pressure just went sky high.

And of course I want to know the reason for my original symptoms. Are they connected to this current problems, or am I falling apart in all categories?

OK, a little too dramatic now, perhaps? The truth is that I'm not really worried. At least yet. I feel great (after they helped get down the blood pressure) and every test they made has been negative. Hey, now I even know that I don't have diabetes!

Monday February 25, 2008

02:07 PM

SOAP

Recently I had to implement a SOAP client and a SOAP server. Well, I didn't actually have to, I volunteered. Shows how stupid I am.

I will start with the conclusion. Note that this is my opinion, others may disagree, but Perl and SOAP don't match. Not quite yet, at least. I mean, SOAP is designed by a committe and adopted by the Java community and Microsoft. I can't imagine anything more developer unfriendly. In the other corner we have our more or less relaxed “We can do it” Perl. But I found hope. More on that later.

My last visit to SOAP in Perl land was some 5-6 years ago when the World was young and Perl land was unstructured as Hell. (Actually I don't know if Hell is unstructured or not, perhaps it's written in Java. That would make sense, I guess).

But I digress. At that time there was only one real choice if I recall, SOAP::Lite. The “Lite” in SOAP::Lite is a misnomer. Perhaps it started out as Lite, but now it just feels big and bumpy.Actually, as far as I can see, SOAP::Lite really only supports RPC/Encoded. The documentation mentions partial support for Document/Literal but I believe it's not really there.

RPC/Encoded doesn't really fit the bill if you want well structured schema based remote actions, so for this Catalyst project, so I was aiming for RPC/Literal. There's also Document/Literal, but RPC/Literal fits almost exactly together with Catalyst's Component model.

I've already complained about SOAP::Lite, but fortunately there's a new module that can compile schemas and apply them to SOAP. XML::Compile from Mark Overmeer seems like a fresh breeze of air and just understands the SOAP protocol.

Daniel Ruoso has built Catalyst::Model::SOAP and Catalyst::Component::SOAP on top of XML::Compile in order to help build Catalyst applications easier. I would add that the Model part feels almost finished. The Controller bit needs a lot in the SOAP Envelope packing/unpacking. But at least it got me going.

Developer pain.Some of you may know already – and somewhere in a dark spot in my mind I had it stored – that you need a WSDL file when doing SOAP. Wouldn't it be nice to have a tool to write it for you? My hopes where high when I found Pod::WSDL on CPAN. It's a really nice idea to embed the parameter and type informaion in the methods Pod. But again, Pod::WSDL can only output RPC/Encoded.

Now, WSDL files are not hard to hand write if you know what you are doing, it's just a tedious and error prone task. So if you have some spare time, pick up Pod::WSDL (it's unmaintained at the moment) and add RPC/Literal and Document/Literal. The source code looks well laid out and easy to understand. Please implement a more economic solution for complex types. If each complex type really relly needs its own package, at least make Pod::WSDL find it within one file.

As an added benefit, by implementing SOAP in the Catalyst application I got rid of Catalyst::Plugin::XMLRPC. That's a good thing because it had a mysterious habit of leaving all the requests as open files. I mean A LOT, it could be thousands, depending on how busy the 'webservices' bit was.

I have plans to extend Catalyst::Controller::SOAP with some SOAP Envelope unpacking and response handling based on the wsdl file. When I get time...

Promises, promises

One important part of human interaction is that you can trust someone and that you yourself is trustworthy.

This is even more true when you do project work. In fact that is the contract between the project management and developers - and between developers themselves.

I don't know how often I've put in an effort to lift my part of the work, only to find that others really couldn't care less about the deadline, the users or the customers that really really need this project to finish.

My usual response is to try to help, lifting some of the work that others should have done. Sometimes I get so tired of this that I want out.

I think the problem has been escalating lately. Or is it just me being more sensitive?

Wednesday December 05, 2007

07:29 AM

New job

I started on a new job a couple of weeks ago. Not that I was tired with my old, on the contrary. But some project related things got to me, I must admit. I wish project management would be taken seriously more places than it does.

Here in Novozymes I work with Catalyst, DBIx::Class and Postgres. Couldn't be better. Mason instead of TT, but it's a matter of taste.

The application is a couple of years old already, so there is an existing code base to care about. But I'm rather optimistic about that we'll move quickly from here. At least that is what I'm hired to do.