mbox must be about the worst designed format ever, this week in a small office I consult for, a few of the staff started complaining they couldn't open some of their mailboxes. It didnt take long to realize that the server was overloaded. 10 people, each had an inbox averaging 500Mb, and outlook checking email every 3 minutes, a few of them also doing a full scan of their imap folders checking for new mail, which range from 2->4Gb.
The poor server was suffering badly, so yet again, I investigated IMAP servers. I've tried cyrus, courier, uw-imap and while each has advantages cyrus and courier have tended to be a little annoying to set up, messing around with auth and protocol issues. uw-imap is the root cause of the above issues (although mbx format does help alot). I was interested to find bincimap (binc is not courier). The overview points out that it's a pure maildir backend mail server (which usually perform pretty well with a cache, and dont have interface issues with folders containing folders not being usable). It also appeared to be pretty simple to set up, although no examples for use with exim where obvious.
I tested the installation on my development box, and after a bit of hunting around and guesswork, I put together simple instructions for converting a exim4/uw-imap installation to exim4/bincimap. The only downside to the conversion was that I lost all my "important" flags from thunderbird. I was actually quite impressed that my own instructions where so amazingly simple.
mono/ASP.net and C#
My experiments with ASP.net and C# have been contining, highlights of this week where discovering that codebehind, without VS.NET is a real waste of time, the codebehind concept assumes that you want to have a compiled .dll. So if you are developing a web page with codebehind, your roundtrip testing becomes edit/build/(install)/test.. I may as well write it in C!!!, at least you can compile that on the fly (tcc a very nice small C compiler).
After playing around with various <% language="C#" src="..."> options, I eventualy came up with the kludge of doing quasi virtual includes
<!-- #include "lib.cs" -->
It's far from clean (it feels a bit like working with function libraries), but at least it works.
Next on my challenges was getting ASP.Net working with mysql, This is a challenge in it'self (I ended up copying the bytefx.dll into my web root's bin directory to get the import working). From what I gather, ByteFX who wrote one of the main mysql connection toolkits for .NET, (which looks like it is now owned by mysqlAB) is unfortunatly not very well documented. The example on the go-mono.org site works, but It did not take long to be reminded that if you want to work with C#, you have to think the Microsoft way. The one true solution, or the one true solution (both of which look good on the face of it, but are shit round the edges.)
Any good PHP programmer knows that sending raw data from a URL to the database is a security nightmare waiting to happen. So we have these wonderfull features like addslashes, and mysql_real_escape_string(). - normally hidden nicely in a DB abstaction layer. We also get to use bound parameters in some database backends that are designed that way. The .NET way is take parameters or give up.. - you cant escape strings, you must use parameters. (excuse my memory here - this example may need fixing) eg.
mycmd.executeText = "select * from sometable where name=@name";
MysqlParameter param = new MysqlParameter("@name", MysqlType.VarChar);
param.Value = "some'test";
mycmd.Parameters.Add(param);
A couple of problems with the above code come to mind, (apart from it's suffers the .NET problem, adding as much noise as possible to a piece of code, trying hiding the purpose).
MysqlParameter docs are difficult to find, and mostly in javadoc style format - which not exactly informative.
@ is used by mysql for variables, so apparently the @ will get changed to ? later...
Debugging what is actually going to the server is impossible! (as far as I could tell). I ended up turning debugging on , on the server, just to be sure what data was ending up at the server.
I can't say it's all bad, but it get very difficult to see the gem's between the rocks when you spend your time writing simple methods to solve common problems all the time.
Client ever asked you to turn a HTML table into a excel spreadsheet?
Given one hour to convert a complex piece of data retreival code to output to an excel file. The thought came to me, why not do it in javascript, based on the existing HTML. write a small piece of javascript that iterates through a HTML table, and posts a form with the data as a CSV to a 2 line PHP script. This is the HTML
<form method="POST" action="quickexcel.php" onsubmit="return toExcel('data')"> <input type="hidden" id="exceldata" name="exceldata" value=""> <input type="submit" name="_submit" value="Download as Excel"> </form> <table id="data"> ...... table with data ...... </table>
you can see the javascript here (it's pretty simple) and the two line php file.. <?php
Previous Topic
