Simon Fell > Its just code > December 2003

Tomorrow we get to find out if RESTLog will handle the year roll-over.

Wow, looking at the netcraft uptime report Apache seriously rules the roost.

Finally managed to finish reading Quicksilver, It took quite an effort to read, it never got to the "can't put it down" phase that other Stephenson books did. Now I can get to work on the backlog of books that have piled up.

I was wondering why I was getting referrer hits from http://www.diveintomark.org/, so went to check it out and found a link to proxytrace with a title of "not that i would ever admit to debugging soap and wsdl applications, but hypothetically, it could save my ass in my day job", which gave me a good chuckle, thanks Mark.

For me at least, I came back from Christmas break to 611 emails, all of which were spam!

Happy Holidays to all those who celebrate such things at this time of year!

The Juice finally came back on at 9.20 PM tonight, making a 27 hour 23 minute power outage, the only good thing is that I got to read a bunch of Quicksilver, and only have about 100 pages to go now. Oh, and automated power outage report that PG&E have either sucks, or wasn't been updated, as it was claiming I had power when I didn't. Do they have anything that actually works ?, ever since I moved to SF PG&E just seem to be stumbling from one fiasco to the next.

The blackout continues, fortunatly the Starbucks at 3rd & Howard, has power, coffee and internet connections, so I'm going to be camped out there for a while.

I've updated my Atom feed to v0.3, note that it's now at a new location. The feed validator says its not valid, I disagree, the spec says that xml:base should be applied, so relative URL's shoudl be fine.

Arrrggggghhhhhhhh, It was bad enough when I found out that HttpResponse.WriteFile would load the whole file into memory before writing it to the output stream, but at least that can be fixed with a few lines of code. But now I see that the whole request also gets buffered in memory (in HttpRequest.InputStream() ) making it impossible to use ASP.NET to upload large files (or even lots of moderately sized files simultaneously). Sigh, this is pretty poor design, IMO, files can obviously be multiple times larger than available memory, the HTTP request / response is modeled as streams for a reason, don't fuck it up by trying to drop the whole thing into a byte array at some point. Perhaps if Stream.Copy existed I wouldn't keep seeing this problem (WSE 1.0 does something similar, which I'm sure KeithBa is fixing for 2.0, right Keith ?). Anyone know if this gets fixed in Whidbey ?

Update There are comments over on Drew's blog that as WSE is built on ASP.NET, that WSE can't fix the problem, however I was refering to the WSE client buffering everything, not the server (but obviosuly the server does as well). However I don't buy that the WSE team can't fix this, if Software Artisans can write a product to handle large uploads in ASP.NET, then I'm sure the WSE team can equally come up with a workaround the ASP.NET problem, til the ASP.NET team get it fixed.

Support for SOAP 1.2 is about complete, I'd like the 2.0 release to include support for the new MTOM (a variation on SwA) attachment spec which is currently being worked on, but this pushes the 2.0 release out even further, so I may release an interim 1.5 version which contains the SOAP 1.2 support along with some bug fixes, but not the new attachments or serializer infrastructure. Comments on whether a 1.5 release is useful to anyone are welcome.

There's also a new version of the WSDL wizard in the pipeline that includes improved support for xsi:nil and for type hierarchies amongst other things.

There's a new revision of PocketHTTP in the pipeline, I'm currently working on one outstanding issue regarding SSL on PocketPC 2003, once that's resolved it will be released. Along with the SSL on PocketPC 2003 support, the new version includes a few bug fixes, and support for gzip compression (In addition to the current deflate compression support).

There's a new release of YATT available, this now uses winpcap 3.0, and incorporates various bug fixes.

There's also a new release of TcpTrace that fixes the long standing bug of it not telling you when it can't listen on the port you asked for.

Finally got around to getting the store sorted out, now you can show your support for PocketSOAP and buy a t-shirt or other goodies, proceeds go towards bandwidth bills and development software/hardware.

Although I have a reputation for saying unflattering things about Microsoft (Its good to be critical, it means I'm paying attention), I continue to be impressed with just how productive I can be coding in C# with the .NET framework, for example this afternoon I need some code to resize graphic files, which is all of 3 lines of code. (and 10 minutes reading the docs). Sure things could be better, in particular the granularity of some things (e.g. the ValidateRequest feature in ASP.NET), but even so my overall productivity is way up. This was particularly brought home to me after working on ASP.NET and Winforms stuff and having to go back and do some MFC GUI work (shudder!).

Have been digging further on my earlier SSL on PocketPC 2003 problem, and have found that if i don't put the socket into non blocking mode, then it works fine, however i need to use the socket in non blocking mode because there are bugs with using select with SSL with blocking sockets. Sigh