Cook Computing

I've read various blog entries on the future of IE or lack thereof. Here are my predictions of what will replace it:

• Browser incorporated into much richer Windows Explorer shell.
• Unified UI for viewing/editing all data (web, local documents, email, RSS(?), etc, etc).
• Shell Extensions in managed code to achieve this (well documented!).
• Unified search functionality for all above data sources (plumbed in again via managed APIs).
• Better support for running rich downloadable smart clients (written in managed code using a much superior framework to WinForms).

I think a key aspect will be the use of managed APIs to make it much easier to incorporate 3rd party products into this environment. The improved support for downloadable clients will appeal to the corporate market and will make it easier to sell licenced software running under DRM.

I'm learning a lot about XSLT. It seems that use of disable-output-escaping, such as in my recent post, is bad. It only works if the output is going to be used as text or parsed by an XML parser, not if it going to be passed on as a DOM, for example, (presumably because you are putting unescaped XML markup in a text node).

I stayed up late last night and found a better solution to the problem. This uses the following-sibling axis to traverse the list of formatting elements. Nested calls to apply-templates are used to nest the <i> elements within the <b> elements.

<xsl:stylesheet version = '1.0' 
     xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>

  <xsl:template match="p"> 
    <p>
      <xsl:apply-templates select="r"/> 
    </p> 
  </xsl:template> 

  <xsl:template match="r"> 
    <xsl:choose>
      <xsl:when test="rPr/*">
        <xsl:apply-templates select="rPr/*[1]"/> 
      </xsl:when>
      <xsl:otherwise>
        <xsl:apply-templates select="t"/> 
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template> 

  <xsl:template match="r/rPr/b" priority="1">
    <xsl:call-template name="emit-format"/>
  </xsl:template> 

  <xsl:template match="r/rPr/i" priority="1">
    <xsl:call-template name="emit-format"/>
  </xsl:template> 

  <xsl:template match="r/rPr/*">
    <xsl:call-template name="ignore-format"/>
  </xsl:template> 

  <xsl:template name="emit-format">
    <xsl:element name="{name()}">
      <xsl:apply-templates select="following-sibling::*[1]"/>
      <xsl:if test="not(following-sibling::node())">
        <xsl:apply-templates select="../../t" />
      </xsl:if>
    </xsl:element>
  </xsl:template> 

  <xsl:template name="ignore-format">
    <xsl:apply-templates select="following-sibling::*[1]"/>
    <xsl:if test="not(following-sibling::node())">
      <xsl:apply-templates select="../../t" />
    </xsl:if>
  </xsl:template> 

</xsl:stylesheet> 

The one thing I don't understand about this is why I need to raise the priority for match="r/rPr/b" and match="r/rPr/i". As an XSLT neophyte I would expect them to be more specific than match="r/rPr/*" and so have higher priority.

I'll be attending the MSDN evening event on Configuration and Management of .NET Enterprise Applications at Microsoft UK on Tuesday June 10th (via Richard Blewett).

I'm currently learning XSLT and I've come across a problem which I can solve but only in what seems like an inelegant way. Given this example source document:

<p>
  <r>
    <t>Some </t> 
  </r>
  <r>
    <rPr>
      <b /> 
      <i /> 
    </rPr>
    <t>formatted</t> 
  </r>
  <r>
    <rPr>
      <b /> 
    </rPr>
    <t> text.</t> 
  </r>
</p>

I want to transform it into something like this:

<p>Some <b><i>formatted</i></b><b> text.</b></p>

The problem is how to achieve the nesting of the text within the <b> and <i> tags. The following stylesheet seems to work but I don't like the use of the text elements with the disable-output-escaping attribute set. There is sure to be a right way of doing this but it has eluded me so far.

<xsl:stylesheet version = '1.0' 
  xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>

  <xsl:template match="p">
    <p>
    <xsl:apply-templates select="r"/>
    </p>  
  </xsl:template> 

  <xsl:template match="r"> 

    <xsl:if test="rPr/b"> 
      <xsl:text disable-output-escaping="yes" >&lt;b&gt;</xsl:text>
    </xsl:if> 
    <xsl:if test="rPr/i"> 
      <xsl:text disable-output-escaping="yes" >&lt;i&gt;</xsl:text>
    </xsl:if> 

    <xsl:apply-templates select="t"/> 

    <xsl:if test="rPr/b"> 
      <xsl:text disable-output-escaping="yes" >&lt;/i&gt;</xsl:text>
    </xsl:if> 
    <xsl:if test="rPr/i"> 
        <xsl:text disable-output-escaping="yes" >&lt;/b&gt;</xsl:text>
    </xsl:if> 

  </xsl:template>

</xsl:stylesheet>

I've hugely simplified the source document and removed namespaces - for the purpose of illustrating the problem - but you may be able to guess what I'm trying to do from the element names.

UPDATE: I made the classic mistake of pasting a change into a sample without testing it. I've now corrected the final <r> element.

As has been discussed many times, deterministic finalization is not possible in managed code. But another form of deterministic mangement of resources is possible through the use of leasing, using the fact that an object is disconnected when a lease times out. We can use this to ensure that the resources held by an object are released either within a specified time period from the creation of the lease if no calls have been made to the object, or a specified timeout period after the most recent call to the object. When the lease times out and the object is disconnected, we call the object's IDispose method if it implements the IDisposable interface used to indicate that an object requires explicit cleanup.

To use leasing the object must be in a different AppDomain to its clients. If the client is in a separate process then this is obviously the case, whereas in the in-process case we need to create a separate AppDomain in which we instantiate the object.

Trapping the disconnection event is achieved by registering an instance of the ITrackingHandler in the AppDomain where we are creating the object:

interface ITrackingHandler
{
  public void MarshaledObject(object obj, ObjRef or);
  public void UnmarshaledObject(object obj, ObjRef or);
  public void DisconnectedObject(object obj);
}

The DisconnectedObject method of the handler is called by the Remoting infrastructure when the connection between the client and our object is broken. Disconnection can happen for various reasons such as the client process terminating, the client object being garbage collected, or, of most interest here, when the client's lease on the object expires.

Building on the sample code from the recent post on configuring leases, the factory class is extended to implement ITrackingHandler:

public class ClassFactory : MarshalByRefObject, ITrackingHandler
{
  public ClassFactory()
  {
    TrackingServices.RegisterTrackingHandler(this) ;
    LifetimeServices.LeaseManagerPollTime = TimeSpan.FromSeconds(1);
  }

  public object Create()
  {
    TestClass obj = new TestClass();
    ILease lease = (ILease)obj.InitializeLifetimeService();
    if (lease != null)
    {
      lease.InitialLeaseTime = TimeSpan.FromSeconds(5);
      lease.SponsorshipTimeout = TimeSpan.FromSeconds(5);
      lease.RenewOnCallTime = TimeSpan.FromSeconds(5);
    }
    return obj;
  }

  // ITrackingHandler methods
  public void MarshaledObject(object obj, ObjRef or)
  {
  }
   
  public void UnmarshaledObject(object obj, ObjRef or)
  {
  }
    
  public void DisconnectedObject(object obj)
  {
    if (obj is BaseClass && obj is IDisposable)
      (obj as IDisposable).Dispose();
  }
}

The ClassFactory constructor registers the handler and also sets the LeaseManagerPollTime to configure the time interval between each activation of the lease manager when it checks expired leases. The default interval is 10 seconds but a smaller timespan is used to here to make when disconnection happens more obvious when running the sample code.

We don't necessarily want IDispose to be called on every object which is disconnected in the current AppDomain so we restrict this to classes which derive from the sample BaseClass which is used as the base class for all classes on which we want to manage resources.

public class BaseClass : MarshalByRefObject
{
  ILease _lease;

  public override Object InitializeLifetimeService()
  {
    if (_lease == null)
      _lease = (ILease)base.InitializeLifetimeService();
    return _lease;
  }
}

Note that BaseClass must derive from MarshalByRefObject. The override of InitializeLifetimeService allows the factory class to set the lease (as described in the recent post). We then derive from this class, implementing IDisposable if cleanup is required:

public class TestClass : BaseClass, IDisposable
{
  public string GetAppDomainInfo()
  {
    return "AppDomain = " + AppDomain.CurrentDomain.FriendlyName;
  }

  public void Dispose()
  {
    // free up resources held by object
    Console.WriteLine("Dispose called");
  }
}

Finally, we need some code to drive all of this:

public class App
{
  public static int Main()
  {
    AppDomain ad = AppDomain.CreateDomain("ResourceDomain", 
        null, null);
    ObjectHandle oh = ad.CreateInstance("TestLeaseTimeout", 
        "ClassFactory");
    ClassFactory factory = (ClassFactory)(oh.Unwrap());

    TestClass tc = (TestClass)factory.Create();
    string info = tc.GetAppDomainInfo();
    Console.WriteLine("AppDomain info: {0}", info);
    System.Threading.Thread.Sleep(20000);
    return 0;
  }
}

We create a child AppDomain and instantiate the factory class within it. We create an instance of TestClass, make a call on it, and sleep to allow for the object to be disconnected and its Dispose method called.

This technique is a coarse-grained and fairly expensive way of managing resources but it can be useful. The more obvious examples that spring to mind are where a remoted client acquires objects on the server and the server-side objects acquire valuable resources. If the client fails to dispose of the objects then we want to reclaim the resources within a fixed period of time rather than relying on garbage collection.

I've spent some time over the weekend investigating ways of making it easier to write blog entries. One feature which I'd like is an simple way of generating footnotes. Ideally I'd like to use the <SUP> tag to display the reference in the text but I found that browser rendering is not up to that yet. If you use ^superscript you typically get any ugly increase in line spacing.

After much messing around with browser-specific CSS, for example setting the superscript font size to 75% on IE and 50% on other browsers, I realized that although I could get something working for specific browsers and a specific font, as soon as I moved to a different font the line spacing problem appeared again on at least one of the browsers.

This page offers some alternatives. I think I'll go with the first, most simple, approach[1].

[1] See this example.

I've been experimenting with .NET leasing and I came across a problem. I wanted to configure the lease of an object from a factory class instead of overriding the InitializeLifetimeService method of the object's class. The latter technique is well documented and looks like this:

public class MyClass : MarshalByRefObject
{
  ...
  public override Object InitializeLifetimeService()
  {
    ILease lease = (ILease)base.InitializeLifetimeService();
    if (lease.CurrentState == LeaseState.Initial)
    {
      lease.InitialLeaseTime = TimeSpan.FromSeconds(10);
      lease.SponsorshipTimeout = TimeSpan.FromSeconds(10);
      lease.RenewOnCallTime = TimeSpan.FromSeconds(10);
    }
    return lease;
  }
  ...
}

My factory class is used to create objects of different types and instead of overriding InitializeLifetimeService in each of these classes I wanted to do something like the following:

public class TestClassFactory : MarshalByRefObject
{
  ...
  public object Create()
  {
    // in real code can create different types here
    object obj = new TestClass();
    ILease lease = (ILease)obj.InitializeLifetimeService();
    if (lease != null)
    {
      lease.InitialLeaseTime = TimeSpan.FromSeconds(10);
      lease.SponsorshipTimeout = TimeSpan.FromSeconds(10);
      lease.RenewOnCallTime = TimeSpan.FromSeconds(10);
    }
    return obj;
  }
  ...
}

Unfortunately this has the flaw that when the Remoting framework calls InitializeLifetimeService a different lease is returned and the above settings are ignored. The lease which is being initialized above must be returned in the framework's call to InitializeLifetimeService so we need to override InitializeLifetimeService so that the base class's version of the method is only called once:

public class MyClass : MarshalByRefObject
{
  ...
  public override Object InitializeLifetimeService()
  {
    if (_lease == null)
      _lease = (ILease)base.InitializeLifetimeService();
    return _lease;
  }
  ILease _lease;
  ...
}

This code can be factored out into an intermediate base class. All the types to be created by the factory class can then be derived from this class instead of MarshalRefObject which means they need not override InitializeLifetimeService:

public class MyBaseClass : MarshalByRefObject
{
  public override Object InitializeLifetimeService()
  {
    if (_lease == null)
      _lease = (ILease)base.InitializeLifetimeService();
    return _lease;
  }
  ILease _lease;
}

public class MyClass : MyBaseClass
{
  ...
}

public class MyOtherClass : MyBaseClass
{
  ...
}

In Web Services, Weblogs and the Future Timothy Appnel discusses the state of blogging APIs. He identifies three key issues in the design of any universal interface, international character support, robust extensibility and cohesion with RSS, with the former being the most important:

The most important amongst these issues is XML-RPC's lack of international character support. Adriaan Tijsseling noted to me that Apple's WebServicesCore and MovableType's API support UTF8 in XML-RPC, but according to the XML-RPC specification strings are limited to ASCII thereby undermining international character support. There have been numerous threads in the past on this issue such as this one made by Charles Cook.

Regarding extensibility:

To a lesser extent, but still significant, is robust extensibility. As weblogging expands and evolves, feature sets will become more diverse and feature sets in tools will begin to vary and hybrids emerge. What effect will this have on interoperability? What XML-RPC lacks is a straight-forward and reliable way for it to be extended when warranted -- whether that's between two weblogs or two million. In comparison to straight XML, a XML-RPC struct is not straight-forward -- its quite verbose. Structs in XML-RPC don't have the benefit of utilizing namespaces and thereby cannot directly leverage previous work such as Dublin Core. Back in January, Sam Ruby published "Evolution of the Weblog APIs" that amongst many things, highlights this issue by comparing the implementation of services with XML-RPC and other formats.

Timothy decides that these issues can't be addressed in XML-RPC because the spec is frozen and I agree that we are unlikely to see any change to structs. However I think we are seeing a de facto move to supporting UTF-8 in XML-RPC. Timothy mentions a couple of examples, and this Evhead entry mentions the current Blogger work on encoding and internationalization which I suppose means that UTF-8 encoded text will be flowing through their XML-RPC interfaces.

[The blog entry of mine he links to was written when I was wasting a lot of time trying to develop .NET interfaces, for use in generating XML-RPC proxies via XML-RPC.NET, for the Blogger, MetaWeblog, and associated extensions. That was very frustrating, hence the tone of the entry.]

One for Gwyn (via Early Adopter): Management (WMI) Extensions for Visual Studio .NET 2003 Server Explorer.

This component adds WMI-based management extensions to the Visual Studio .NET Server Explorer tool through two new nodes, Management Classes and Management Events. Management Classes allow the developer to browse and modify WMI data as well as invoke methods. Management Events enable the developer to register for WMI events. Data and events can be easily added to an application being developed.

The .NET Magazine article Exchange Server 2003: Worth the Upgrade? mentions a new set of Exchange APIs:

Microsoft is readying a new set of Exchange APIs called the Exchange Server Objects (XSO). When XSO ships (probably a few months after Exchange Server 2003), developers will finally get a remoteable, server-safe object library, based on (and designed for) .NET managed code. You can expect to hear more about XSO in the future, and it should make integrating Exchange data into the rest of your organization much simpler.

I'd not heard of this before and I couldn't find anything about it on MSDN or via Google. An article on the Register doesn't add very much:

Titanium functionality will be exposed to third parties via the XSO managed API. XSO gives developers a single, XML-based interface to write to when developing web services. This means the Exchange calendar, diary or in box could be populated with data from an outside application without using the traditional Collaborative Data Objects (CDO) route.

Jim Bernardo, .NET enterprise server group product manager, called XSO an "order or magnitude" different to CDO because it reduces development effort and is remotable. XSO also support Microsoft's Common Language Runtime (CLR).

When I moved this website to a new hosting service one of the problems was that the Perl module for Berkeley DB was not available on the new server. MySQL was available, so I had to export the contents of the blog to a text file and import them into a newly created blog on the new server.

This works fine except that if you have ever deleted any entries from the blog, the numbering of entries in the destination blog will be different. The MT export routine simply writes out the entries sequentially, ignoring entry id's, and the import routine creates a new set of entries sequentially starting from 1. Some extra work is required to retain the numbering of your entries and so maintain the validity of the entry permalinks.

The first step is to change the export process so that the entry id is output with each entry. In the mt/App/CMS.pm file, modify the export subroutine to add a line writing the ID, for example:

...
AUTHOR: <$MTEntryAuthor$>
ID: <$MTEntryID$>
TITLE: <$MTEntryTitle$>
STATUS: <$MTEntryStatus$>
ALLOW COMMENTS: <$MTEntryFlag flag="allow_comments"$>
CONVERT BREAKS: <$MTEntryFlag flag="convert_breaks"$>
ALLOW PINGS: <$MTEntryFlag flag="allow_pings"$>
PRIMARY CATEGORY: <$MTEntryCategory$>
...

Export the entries from the blog to a text file, say mt.txt. The exported entries now need to be sorted by entry id with dummy entries being inserted to fill the gaps (the id's must start from 1). At this point I removed the lines beginning ID: but this may not be necessary. Import the entries into the empty blog and then delete the dummy entries. Finally verify that the process has been successful and the entry id's in the new blog are the same.

One other problem I encountered was unless the MySQL database is new you will find that the imported entries will not be numbered from 1. A quick way of completely re-intializing the MT tables from the database is to add the following to mysql.dump. Then run mt-load.cgi to re-load MT from scratch.

drop table if exists mt_author;

drop table if exists mt_blog;

drop table if exists mt_category;

drop table if exists mt_comment;

drop table if exists mt_entry;

drop table if exists mt_ipbanlist;

drop table if exists mt_log;

drop table if exists mt_notification;

drop table if exists mt_permission;

drop table if exists mt_placement;

drop table if exists mt_plugindata;

drop table if exists mt_template;

drop table if exists mt_templatemap;

drop table if exists mt_trackback;

drop table if exists mt_tbping;

Note that this may need to be changd for any version of MT other than 2.63. I guess a similar approach could be used for PostgreSQL or SQLite.

I've moved to a different hosting service, hence some of the teething troubles over the last couple of days. I've learnt a few things about hosting Movable Type on a Windows system with IIS and moving exporting/importing a blog from one Movable Type installation to another. I'll write these up at the weekend.

One significant change is that I don't have to worry about bandwidth charges anymore and I have switched to full content in the feeds. Also, I can now use ASP.NET and will be setting up various sample XML-RPC.NET services.

Sam Gentile points to the MSDN article .NET Remoting Architectural Assessment by Pat Martin. This is well worth reading if you're thinking of using .NET Remoting in your product or application.

I found the section on authentication particularly interesting in light of my recent post which moaned about the lack of built-in security functionality in Remoting:

...To start with, you need to build your own authentication and authorization mechanisms, should you require them. The article .NET Remoting Security Solution, Part 1: Microsoft.Samples.Security.SSPI Assembly provides a very full and detailed description of a security solution for .NET Remoting that " ... implements a managed wrapper around SSPI, providing the core functionality needed to authenticate a client and server as well as sign and encrypt messages sent between the two." This is definitely a great asset and provides a "façade" for adding this functionality in a useful way. The problem is that it is not a supported product but an "informal" attempt to supply missing functionality. Also, it's a little intimidating for a developer, as the solution relies on the extensible nature of formatters and channels. All this needs to be hidden and the functionality surfaced by just adding an entry to the Remoting configuration, which depicts, for example, the use of Windows NT Challenge/Response (NTLM). It is likely, however, that such security mechanisms will be incorporated into a future version of .NET Remoting.

Another issue with Remoting is performance, again something I've discussed here. Using Named Pipes as the channel transport provides better performance than TCP so it is good to read:

So, if you need Named Pipes, Remoting offers a solution. Once again, however (as is the case with the SSPI NTLM authentication solution), this solution is currently unsupported by Microsoft. It is likely that Microsoft may address this requirement at some future date.

I'm posting this from NewsGator 1.2 which has just been made available for download. I only installed NewsGator for the first time yesterday but should have done so sooner. Its an impressive piece of work by Greg Reinacker.

Interesting to note that the XML-RPC-based plugins use XML-RPC.NET. Also that a different plugin is required for each type of blogging engine. I'm using the MovablePoster plugin from Matt Berther. This works well but does not quite fit into my way of working with Movable Type. I use a text formatting filter with Movable Type and I'd prefer the plain text of the entry to be posted to the blog rather than an entry with HTML formatting inserted by the Outlook editor. This would also require the ability to set the text formatting type for the blog.

The killer posting feature for me would be the ability to save a draft in Outlook without posting. Currently doing a Save posts the entry to the blog.

One use Scoble has for blogging:

I use this weblog for a variety of purposes, but lately it's just to keep track of useful stuff on the Internet that I might want to look at later. Believe it or not, I use Google to find links that I've put on my weblog in the past. For instance, when I need plumbing supplies, I just search Google for "scoble plumbing supply" and up comes my weblog where I talked about a plumbing supply place.|

I was recently suprised when I googled for an answer to a .NET question and one of my own posts was the first hit. I don't know whether I was more amused by this or annoyed at having forgotten the answer to the question and that I had posted it.

Diego Doval's review of blogging APIs (via Evhead) overlooks the fundamental problem with XML-RPC in relation to blogging APIs: the inability to pass strings which are not restricted to 7-bit US-ASCII. I know I keep banging on about this but it can't be swept under the carpet for whatever reasons people have. The two obvious solutions with respect to XML-RPC are to encode Unicode strings in some way which is valid according to the XML-RPC spec, for example using the base64 XML-RPC type, or to transition XML-RPC to allow strings with a Unicode encoding.

The comments attached to Diego's post contain an attack on myself and Sam Ruby, one of the criticisms being that we're not really looking for an answer. Actually the post of mine being referred to is a suggestion about using WSDL for improving interop with XML-RPC. It may be a crap idea but it was an attempt to suggest a solution to a real problem. By the way, I just re-read the post and failed to see why anyone would think I was "annoyed" when I wrote it.

Just caught this posting to the Mono list in the XML-RPC.NET site referrals:

Thanks to the recent checkin by Paolo, Cook Computing's XML-RPC.net code now works. You can find the assembly code at http://www.xml-rpc.net. Unzip the file in a subdirectory, cd to src, and:

mcs /target:library /out:CookComputing.XmlRpc.dll *.cs -r System.Web.dll -r System.Web.Services

and that's it. There are some demo programs in samples, but they do use System.Windows.Forms, but the code is extremely simple.

I do have a pretty extensive test app I was using with MovableType to do the testing, but a) the code is ugly and b) my blog personal info is embedded in the code...

Good work people!

Mark

Encouraging to see that the Google/Blogger people are working on a blogging API which doesn't assume that bloggers only use a stunted 7-bit version of their language (via Bill Kearny). This is one of the benefits of the heavyweights moving into the blogging arena. Re Scoble's point about blogging standards, I'd be pleased if Microsoft developed a new standard, assuming the right people worked on it. The existing blogging APIs are so ugly and inadequate.

Adam Sills at Surrealization has also discovered the use of .ASHX files (see earlier entry here):

Okay, so I've definitely written my fair share of HTTP Handlers in ASP.NET (i.e., the classes that inherit from IHttpHandler), and when I found out that my website host doesn't support modifying the web.config to allow HttpHandlers made me very upset. Especially when I implemented the Blogger API on my website and wanted to use a free desktop publishing tool (that I'm using now). Anyway, I had given up on using an HttpHandler to implement the XMLRPC method calls the Blogger API uses. I was reading up on something and noticed an ASHX file extension. Did a quick google search and found out that's the OTHER way to create an HttpHandler. I fired up Visual Studio, created an ASHX file, made it inherit my old XmlRpc class and voila! it worked perfectly!

Useful to know if you can't modify the web.config file.

Trawling through my logs last night I came across a scenario which several of the more popular aggregators don't handle. If a feed is returned with the Transfer-Encoding header set to chunked and, presumably because content is being generated dynamically, for example through use of an SSI, no Last-Modified header, these aggregators don't bother sending an If-Modified-Since header. If the server does not support etags either, this results in the feed being downloaded on every request, instead of a 304 Not Modified response.

In this case the aggregator should use the time returned in the Date header as the value to be passed with If-Modified-Since in the next request. If the server supports If-Modified-Since, 304 will be returned unless the feed has changed.

This may be a fairly obscure secenario but other aggregators seem to handle it ok, so it is probably worth coding for. One caveat in this area: if a Last-Modified header was not returned, the LastModified property of the WebResponse class returns the local time on the client machine, not the value of the Date header on the HTTP response. If the clocks on the client and server machines are out of sync then things won't work quite as expected.

Quite by chance I came across this set of photos of the Waymark skiing group I was with this year in Espedalen, Norway. I'm wearing the yellow top. Thanks Alan.

I was very unfit this year after just a few months off running following a viral illness. Some of the hills were hard work. Being a software developer is simply no good for you from a fitness point of view. Sitting down barely moving for hours on end, muscles turning to lard, heart atrophying a little every day. I've started running again, several miles a day already, but its a long haul to get fit again.

Ted Leung has updated his list of aggregators and their support for GZIP. I'm one of "a total of two people in the world" who use ChannelBuddy, a great aggregator which predated all other known .NET aggregators by many months but was never released. My apologies for being a bandwidth hog but I'm sure the pair of us aren't causing anyone much of a problem. I can't do much about it anyway: I'm only the test team!

Sam Gentiles entry on an article in the June edition of MSDN Magazine caught my eye because of its suggestion of a solution to the lack of deterministic finalization in .NET, this being one of the major drawbacks of writing managed code. As luck would have it, this issue is the first after my subscription to the magazine expired and the ariticle doesnt go online until next week. However Im sceptical about whether the DF issue can be solved, even with Managed C++. For example, smart pointers are of no use because destructors are called non-deterministically for managed types and so there is no way of knowing when a reference to a managed type has gone out of scope.

The lack of DF, while adding extra work around resource management, does not bother me unduly. My experience with large-scale C++ projects is that memory corruption is a much bigger long-term problem and we can avoid that completely if we stick to verifiable managed code (bye bye C++, though I remember reading that a future version of Managed C++ will be able to generate managed code, presumably allowing only a small subset of C++). Failure to release resources is detected fairly early on during system testing whereas memory corruption can lurk for a very long time before showing itself, usually at an important customer site.

One solution would be to add ref counting to the CLR. I wonder what happened to Chris Sells project to to add ref-counting to Rotor and to study the performance effects?

I was doing some research on leasing today when I came across a misleading rationale for leasing in Ingo Rammer's excellent book Advanced .NET Remoting. He explains that the pinging mechanism used by COM involves the server pinging the client and so:

Unfortunately, when your client is behind an HTTP proxy and is accessing your objects using SOAP remoting, the server will not be able to contact the client in any way.

This leads to a new kind of lifetime service: the lease-based object lifetime.

This is wrong. In COM the client pings the server and so this could be implemented over HTTP through a proxy. Leasing, although much more flexible than COM pinging, is not inherently different to pinging. Its just that in the COM case the "lease" is initially 6 minutes and the client COM runtime has to renew the "lease" manually (by pinging the server) without any sponsorship mechanism to warn that the "lease" is about to expire.