[Technical]

After answering Peter's comment to my last entry on the threshold of complexity required before moving to an HttpHandler-based web application, I've done some more thinking.

I originally mentioned that threshold is reached when you start thinking about the application in terms of a flow or state machine, but that test would indicate everything but the most basic "list-of-standard-reports" web application would merit this approach.  While it is true that all of them would benefit from the approach, I think it's important to think about Microsoft's vision for ASP.net, which was to speed development, and provide a more power YET FAMILIAR framework for building web applications.

It's the familiar part that's most important.  People have been creating Handler-based solutions all along using ISAPI filters, and .NET reduces the complexity of this approach IMMENSLY using IHttpHandler, even thought it is significantly more complex than the classic ASP page model.  .NET reduced that effort as well.

I think .NET brings simplification to both approaches.  Most people creating handler-based approaches already have a significant amount of conceptual design in their current systems. and probably wouldn't use any canned solution for such an approach.  However, classic ASP developers were overdue for improvement.

I believe most applications would benefit from a handler-based solution, but without a standard coding model for this, most developers will feel more comfortable with the page-based model.  What's worse, Microsoft's suggested implementation still relies on the Page class, without explaining fully how to handle complex user interaction in this hybrid environment.

I'm afraid I haven't answered many questions.

[UPDATED 9:15 same day after reviewing dasBlog source code]

When should you stray?  As soon as you're ready.