Older blog entries for jmason (starting at number 37)

Installed Postfix at home and in work. It's very nice, and I feel a lot more comfortable about it than s*ndmail. And I really appreciate Wietse Venema's design...

I read all the recentlog.html diaries last night at 1900 GMT before writing yesterday's entry. It's now 1300 GMT and my entry has already scrolled off the bottom. Looks like the diary system's not scaling... :(

New at Joel on Software: a critique of MS' latest vapour tactics regarding .NET.

Basically Joel's question is: "where's the beef?" I've been wondering that too, to a certain extent; it's all very well predicting that SOAP will change the internet, but I can't really see the diff between it and CORBA apart from it being (a) easier to support and (b) an XML-based protocol (that's a good thing in this case, IIOP is just messy IMHO).

BTW Joel is fantastic, I highly recommend this site.

Looking at the MSDN doc on SOAP's firewall traversal system, I notice an interesting thing -- they've worked around the tricky callback-through-firewalls problem by not dealing with it at all -- there's no such thing as an object reference for an object in the client, it seems.

In other words. a SOAP server cannot notify a SOAP client asynchronously unless it's designed into the interface, presumably with e.g. a client making a call that will block for a long time until the server has its data ready. In CORBA that would be done by the client creating an object, sending the object reference to the server, and the server could then call back to it.

This bidirectionality however didn't map into HTTP at all well -- which makes the firewall traversal thing difficult. (in fact it doesn't even map into IIOP well either, but that's another story ;)

Nice one for Caolan -- the largest GPL codebase in the world!! Now let's see what code we can nick for our own projects ;)

I notice openoffice.org is built on Tigris. That'll be a good demo of it, we can see what it's like.

BTW there is some kind of issue with sitescooper 3.0.0. The nightly snarfs have stopped getting 1/2 the sites for some reason. Must investigate...

3.0.0 works great. Must release it soon...

Well, after all that I've decided to release sitescooper 2.3.0 as 3.0.0 just to make a slightly bigger noise about it. ;)

Just did the first CVS checkin of it (the ci was delayed due to a problem I had with the sitescooper CVS at sourceforge).

Let's hope I haven't forgotten any cvs adds or I'll be getting angry mails tomorrow morning!

Sitescooper 2.3.0 news: works perfectly on Windows, first time! I'm impressed. Well, when I say it works perfectly, it works perfectly apart from the use of socketpair( ), fork( ) and the like when the -preload fork preloading mode is used. But that's purely an optional tweak that uses some severe UNIXisms so I'm not really surprised by that ;)

Shock horror -- clueful article at ZDNN!

Just added output templates to 2.3.0 -- which means that the output generated by sitescooper is now sedded into a template, rather than gradually built up with static strings and a stackload of conditionals inside the code.

This is a bit nicer and should help with i18n'ing the output for non-english speakers.

volsung: my personal preference for open()/close()-style APIs is as follows:

1. define a struct containing the state info for the API (let's call it API_t). You could even keep the function table and the state included in that struct, for a real C++-like feeling ;)

2. provide a API_new(API_t *) function that initialises it into a sane, unopened state

3. provide API_open(API_t *, ...) function that opens it

4. provide API_close(API_t *) to close it

5. provide API_free(API_t *) to free any dynamic stuff after use.

This is very C++-like in usage, and works pretty well IMHO. The problem with using a plain int as a return type in the open() style is that you then get stuck with handling a lookup table of that-int-to-state-struct mappings. yuck, and AFAICS not really necessary or elegant for user-mode library code...

What do you think?

Released 2.2.9 -- but without all the redirect fixes. 2.3.0 will become the devel version pretty soon, and that can handle all the tricky redirects nicely.

Running low on sitescooper-hacking time again. This will delay 2 things: getting the fixes for the redirect problems out of 2.3.0 and backported into 2.2.9, so that 2.2.9 can be released; and finalising 2.3.0 so that that can be released as a beta.

Too much stuff to do. Argh...

snicker: Dialog with an Internet Toaster (found at More Like This).

jaz hits the nail on the head in the SOAP discussion:

whereas the normal use of HTTP is geared toward passing information between two mutually distrusting applications, one of which is the client and one the server, the point of SOAP is to use HTTP to distribute one application across a network.

That's the bit those pesky network admins won't like about SOAP.

I wonder if SOAP supports a server-to-client callback mechanism? Now that is a whole new world of pain, security-wise...

Finally got around to doing a site file for Advogato. Thanks to David Desrosiers for reminding me, indirectly...