V5 work continues. Today I added the IRC client; rather than using the Java applet again, we're going with Mibbit, which is more fully featured, and runs purely on &#106avascript/AJAX. It's also under active development, and we just embed it, so as they add new features to it those features should just magically manifest themselves at our end. Lurvely.

Let's see, what else have I done? Some refactoring... logging in is now a much simpler codepath. I've added support for reporting bugs directly from the browser page (for logged-in users, at least), which automatically includes useful information in the report like the page you were looking at or various page-level &#106avascript vars. Should make the beta process much smoother. There are also now both RSS 2.0 and Atom feeds for Active Topics in the code.<br><br>I've also done more work on the URI schema - the actual addresses you'll use to access resources on the site. I'm going for a RESTful approach with all this, so getting the URI schema right is less about organising files on the webserver and more about usability; for example, /community/forums/topic.asp?id=123456 becomes /discuss/topic/123456 and so on. It also motivates the design of service contracts going forward.<br><br>I'm generally pretty happy about my choice of WCF - the documentation is good, the framework generally follows the principle of least surprise, integration with third party tech is fine (any .NET or COM library is trivial to work with, plus of course any other web services), and the more I dig into customizing the WCF stack itself - such as for my XSRF filters - the more I feel that I am bending the framework to my will, rather than being forced to conform to its way of working.<br><br>I've only really got one complaint about it, at this stage: while it's very easy to swap out framework pieces for custom components, often those pieces are larger than you really want. That would be fine if it was easy to recreate functionality offered by the part you're replacing, but MS keep most of the relevant helper classes and methods as internal to the WCF assemblies. I'd really like to reuse their code for extracting the body of a POST request as a Stream, for example, but the relevant class (HttpStreamFormatter, I believe) is marked as internal. I can understand that every class they expose publicly is one they have to document, support, and change control, but I think it would be worth it, particularly for people building HTTP apps with WCF.<div> </div>