Rick Strahl

Atlas to carry the ASP.NET World - take 1

At the Professional Developer Conference (PDC) in September Microsoft offered a first glimpse at its AJAX (Asynchronous JavaScript and XML) strategy which has been given the codename of Atlas. As you probably are aware of, AJAX is the current over-hyped buzzword in Web Development. It promises the ability to write richer browser applications and retrieve data from the server to update the content of the current page without having to completely repost the page to the Web Server. The advantage of this type of application is that it provides more efficient usage of the bandwidth available to Web applications and – in many cases – provides a smoother, more responsive and non-flashing user interface that Web applications are typically not known for. On the flipside AJAX relies on more recent browsers and fairly extensive use of client side script code to provide the rich interaction between the browser and server.

The hype over AJAX aside, Microsoft’s first effort in the AJAX space was a disappointing one. ASP.NET 2.0 will ship with a technology called Script Callbacks that is native ASP.NET. Script Callbacks is a simple and quirky, interface based implementation of page callbacks that are entirely bound to the ASP.NET page lifecycle. While functional, the model used in this architecture is both limited and implemented in a way that makes using it rather cumbersome and unnatural. Microsoft developed this technology for internal use early in the ASP.NET 2.0 cycle before AJAX became fashionable. It’s used internally in several of the ASP.NET server controls like the GridView and TreeView to support client side updates of the data displayed.

If you are looking to do AJAX style development with ASP.NET 1.1 or 2.0 today there are other possibly easier and more fully implemented solutions available from the community. I personally like Jason Diamond’s My Ajax.Net and have used it quite a bit internally. Another popular library is Michael Schwarz’s Ajax.NET which is probably the most used AJAX implementation on .NET today. Both are open source and come with source code and more importantly both are easy to use and provide simplicity for the 90% use case scenarios and they work with ASP.NET 1.1 so you can use it in all of your ASP.NET applications.

Atlas to the rescue

Not to be outdone, Microsoft entered the AJAX space for real with the announcement of the Atlas Project just a few weeks before PDC and officially previewed the technology at the conference. As expected Atlas is a very ambitious project and covers a huge range of features that cover a variety of approaches to implementing AJAX style applications. Atlas is slated to be shipped as an add-on to ASP.NET 2.0 sometime in 2006, so it’s still a ways off. One nice thing announced is that Microsoft is planning on shipping Atlas outside of the regular ASP.NET product cycle initially so the product can rev much more quickly than a full ASP.NET cycle. Atlas likely will ship as an add-on assembly (or assemblies) plus a script library that can simply be added to an application. At a later point in time it’s likely that tool integration with Visual Studio will take place resulting in a tighter binding to the core ASP.NET platform.

So what does Atlas bring to the party? A lot of things actually, but it’s important to understand that not all of the features of this overwhelming library are necessary to start doing AJAX style development. Here are the some of the core features:

Web Service Connector Bridge

One of the core features of the Atlas framework is the ability to bring down data to the browser quite easily by using a new Web Service interface that gets hooked by the Atlas framework. This special HTTP handler interface essentially allows an Atlas client application to communicate with a .NET Web Service using the JSON serialization format. JSON is a JavaScript compatible, light weight serialization format that encodes any type including complex type into a string that can be evaluated in JavaScript and provide a type reference. This simple interface allows you to take advantage of existing Web Services – or new ones – to access server side logic from the client applications without all of the overhead that SOAP entails.

This interface is two-way, so you can receive data from a Web Service and you can send it back up to the server using the same mechanism. Atlas can serialize and deserialize the JSON format both on the client and server. To facilitate this process the Atlas client framework includes the infrastructure to manage type information which becomes part of the JSON serialization strings that travel over the wire. What’s really nice here is that in combination with the client side script framework you can return many common types from the server and use them easily on the client. For example, you can return arrays, collections, data tables and data rows and the client framework will provide a CLR like client implementation of that type. Custom types are also supported.

This deceptively simple implementation provides a lot of power to existing applications that might not even want to take advantage of all that the Atlas framework has to offer. This is a close match in functionality to the tools I mentioned earlier only more closely integrated with standard ASP.NET practices.

Web Service methods can be implemented both in a separate Web Service class or can be called directly in the current page. One interesting feature of the page based WebMethod call is that all of the page’s POST data gets written back to the server and the callback with full support for the page lifecycle including access to updated control values and ViewState. The full Web Service interface can work with current ASMX implementations or with Indigo services.

Personally I prefer the external Web Service approach as it promotes better separation of the UI logic and the data service functionality. Using the Web Service also means that the data is much more reusable. For example, if you end up building a true Smart Client application it will be able to consume the exact same data using a standard Web Service from exactly the same code base.

In some preliminary tests I found this mechanism in combination with the rich type support very powerful. The ability to easily pass complex types and collections of types from the server to the client and back makes it quite easy to update the user interface, modify data and send it back without having to resort to writing complex string encoding schemes to pass the data around. For interfacing wit business data this mechanism really provides clean separation of the UI and business layers.

Client Side JavaScript Framework

As mentioned above, Atlas provides a rich client framework that provides many of the core services required by other parts of Atlas. Atlas uses a layered client architecture of services provided by the framework. Most of these layers are internally used such as the rendering features for controls, the browser compatibility layer and the network layer used to send requests back and forth.

But one layer you’re likely to see a lot of in your client applications is the Core framework and Base Class Library which provides a small subset of .NET CLR and BCL functionality on the client side. The Core functionality provides a number of language features that are interesting. There’s namespace support and type registration to provide a simulacrum of typed JavaScript variables. Perhaps most interesting is the client-side BCL implementation which provides support for many common basic classes and structures that are used in .NET development. This means that the code you write on the client script end, looks a lot closer to .NET code than it currently does even if some constructs are bound to quirky JavaScript language features.

Client Side and Server Side Controls and ‘Atlas Script Markup’

In addition to the framework Atlas also provides a core set of controls that provide browser independent implementations of many common ASP.NET controls. What this powerful feature buys is an abstracted control model that alleviates the developer’s need to fully understand the nuances of every browser running on a client. If you’ve ever done any sort of UI development with client side JavaScript you know that the syntax and object models of various controls varies ever so slightly and these client side implemented custom controls alleviate the need to have to code to these browser specific nuances.

It’s hard to tell right now how this works, but the Atlas framework uses these controls internally to manage the browser independent rendering of script code. Examples of this stuff have really not been provided but it was shown by Nikhil Korhan in the Server Control talk at PDC. At the moment these controls are internally used by the Atlas Server Controls and the ‘script markup’ they generate in the client side HTML page. Atlas basically uses declarative script tags to drive functionality through behavior attributes. For example, you tell the control to invoke a method on another control (or data control) to retrieve the data, or set the value of a given property.

The script markup is interesting in that server controls generate their declarative markup to the client as is within an embedded <script type="text/xml-script"> tag. The Atlas client framework then evaluates this script markup dynamically to generate the actual page behavior and layout. In other words, unlike server controls, these controls use the client side controls and framework to manage the parsing and even code generation at runtime in the browser. This takes a moment to grasp. The reasoning behind this client side parsing and execution seems to be to avoid having to generate reams and reams of JavaScript code and injecting it into the page before sending it from the server. By doing it on the client this markup functionality can be easily added to any page and can stay relatively small describing the actions of the page.

Microsoft seems to be emphasizing this declarative style of programming, but that doesn’t mean that script code driven logic is not available. You are absolutely able to drill down to the script level and write the control code and logic yourself. If you do you can take advantage of the control architecture and BCL implementation so you get much richer client side functionality. But keep in mind that some of these features are hacked together around the limitations of JavaScript, like the Type subsystem and Object Oriented featured in general. It’s still JavaScript. Bend it as they might, Microsoft is sticking to a pure JavaScript implementation.

This is all pretty vague at this point as there’s zero documentation, but it shows the direction that Microsoft is headed. The idea for the markup code is that rather than writing potentially browser specific JavaScript code you write declarative markup that the Atlas framework then renders into control code and script code that is dynamically generated and executed at runtime. Bertrand LeRoy has a nice example that demonstrates the server control/markup syntax a lot better than the simplistic PDC labs. In that example, you can get a pretty good idea of what markup will be capable of by providing a very UI centric interface.

While I think that this is a noble goal, I personally have many misgivings about this declarative model, because it’s completely UI centric. You basically map a Web Service (or other datasource) to a property or method of another control, but there’s very little room for custom code that is almost certainly going to be required in addition to 1 – 1 mappings. In addition the markup model introduces yet another ‘scripting’ layer into your applications with yet another different markup syntax. However, all of the markup actually gets translated into JavaScript that eventually executes.

The functionality of this markup reminds of Ruby on Rails to some degree, and it’s a model that I dislike vehemently. I don’t trust code that is handled for me to serve all of my needs and this has the beginnings of a high level description language that doesn’t sit well with me. I have to admit I had similar misgivings about the template driven approach that ASP.NET controls use, and eventually I came around to it once I understood fully what you can and can’t do with that approach. I expect the the same will apply here.

The Good, the Bad and the Ugly

Looking at Atlas in this early stage is a mixed bag. As with many of these types of previews the documentation is nearly non-existent, beyond a few hands-on labs which give a cross section of the features available. The labs are actually quite good at demonstrating a number of common scenarios, from basic to the cool factor type. But, the labs are not a good substitute for documentation. They only address a very minimalist subset of the capabilities and provide absolutely no insight into how things work behind the scenes which is this point would be beneficial.

If you want to know how things work your only avenue is to open up the JavaScript libraries with their bunched up, line-feed removed code and dig through the spaghetti code that is JavaScript even at its best. Most of the meat of Atlas is in the JavaScript. For the server side code you’ll need to dig out your copy of Reflector and start digging into the binary bits. Looking through all of this you’ll find that there’s a lot of implementation code – Atlas has been a while coming at Microsoft.

I spent some time to go through the labs and that worked just fine, but as soon as I started going off the beaten path a number of things started breaking. For example, the Web Service functionality started breaking on even some simple custom types I set up. There’s no exception handling in the Web Service behavior so if anything goes wrong on the server, or you need to notify the client of a non-success result via a SOAPException, the server spits back HTML instead of an Exception or other object that includes an Exception. So even some of the simple steps failed outright. Working on from the labs and trying to use the server control markup to fire custom code also proved difficult – basically I was stopped dead in my tracks almost at every corner due to lack of documentation.

Playing with Atlas at the moment is beyond even bleeding edge technology. Don’t waste your time with it unless you’re willing to dig into the code base and find your own ‘documentation’ there.

But this is understandable from Microsoft’s point of view. It’s meant as a very early glimpse at what Microsoft is doing. I don’t think there’s any hope of doing anything useful with this technology at this time other than check it out and give Microsoft feedback on direction. One thing is for sure: this stuff is likely to change drastically, so don’t get too familiar with what’s there today.

Pain Factor: Client Side Scripting

Atlas provides a lot of technology and functionality at the library level, but it doesn’t provide any new tool support at least not at the moment. I would argue that the biggest detriment to efficient client side and AJAX development is the lack of decent tools to debug your client side script code. Writing client script code is easily 4 to 5 times slower (for me at least) than it is to write the equivalent server side code. Lack of Intellisense, compilation, and the mere lack of decent documentation for the various object models make all of this difficult.

Microsoft is addressing some of these issues with the client side libraries and bringing a more consistent object model to client side code so via the client side markup. By using these client side libraries Microsoft is able to abstract away some of the browser compatibility issues and providing you as the developer with a more consistent single access model to code against. This is an important step in the right direction, but tool support is absolutely required if we are to build applications that will rely on an increasing amount of client side logic.

Client side debugging is not being addressed at the moment. That support is something likely to come in future versions of Visual Studio

Smart Client and Thin Client – No Contest, Yet!

There are some interesting issues that Atlas brings up. It’s obvious to see that Microsoft has heavily invested in Atlas by the sheer breadth that this toolkit attempts to address. With all the talk about Windows Vista and Avalon – uh, Windows Presentation Framework (WPF) and the return of the Smart Client, it’s also clear that Microsoft sees the importance of Web based applications and continues to provide tools to build rich applications for this platform.

Try as we might, rich client advances to date have had very little impact on how Web applications or distributed applications are run at least for outward facing applications. Even though it is now nearly as easy to create rich client applications that run inside of the browser, the Web paradigm is still way, way more prominent than any rich client distributed scenarios. Smart Client applications continue to be a hard sell when it comes to public content. With the coming of WPF and the XAML markup language, Microsoft surely is hoping to have a compelling platform to build rich client applications that can directly run in the browser just like Web applications, but taking advantage of the super rich presentation layer that WPF provides.

There’s no doubt that WPF has huge potential to provide this rich and powerful platform, but it’s by no means a foregone conclusion that it will take off for Web style distributed applications. Imagine that you could build rich applications that take advantage of all that Windows has to offer from rich rendering to advanced layout and databinding running native .NET code that you can actually debug. Wouldn’t that be nice? But I wouldn’t count it becoming a mainstream reality anytime soon, as much as I would love to see it happen.

This smells very much of the Internet Explorer 4.0 model where IE at the time was a much more compelling platform to build Web applications for than most other browsers of the day. But even so it never took off as a dedicated platform with Web developers and developers in general sticking to a more generic approach that worked across platforms. We shall see – I would actually love to be proven wrong by time <g>…

I think Microsoft realizes the continued importance of pure Web development and Atlas is a sign that this path will continue, even if it potentially has a negative impact on the adoption of WPF based Web interfaces. Atlas squarely steps in the path of WPF providing a model for building rich Web applications that can provide a more interactive user experience. Advances in the Web client platform have been in stagnation for quite some time, and hype or not, AJAX is injecting a new vibrancy and energy into the Web application platform. Even in its simplest form AJAX style Web applications can provide a better user experience and more interactive applications at the cost of a more complex client/server model. Atlas promises to ride that wave into new territory and possibilities for Web applications and hopefully provide an easier way for ASP.NET developers to get there.

Time will tell, but it’s an interesting start.

ATLAS bits for RC posted

Microsoft today posted the ATLAS bits that work properly with the September CTP or what has become the Release Canidate (RC) of VS.NET 2005.

http://lab.msdn.microsoft.com/vs2005/eula.aspx?id=63C6B54B-AF8F-453B-869B-0438DBBB781B

I’m so glad – I’ve been screwing around with my Beta 2 VPC that’s seen better days and it’s not been an optimal experience. I’ve been working with Beta 2 for a while and it’s been a frustrating experience at times, but the RC is a huge step up.

Say what you will VPC development sucks. Even with an external HD hooked it’s damn slow compared to the main machine and if you end up switching back and forth between the VPC and host it’s really bad. Add to that the perf difference between Beta 2 and the RC and you end up really not wanting to run the VPC session <g>. I was desperate enough to copy my beta 2 ATLAS project to the RC bits to see if it would run a few days ago, but that didn’t work. None of the ATLAS callbacks were working with some odd low level framework errors.

Anyway, now with bits running on my main machine the going is much easier. Onwards…

A Music Recording Relvation (sort of): I want a noise cancelling pedal

I was screwing around today with a riff that wouldn’t go out of my head, so I decided that I need to record it. I’m in Hood River and have only a little bit of my recording gear with me and it’s not set up. So after about an hour of getting set up I was finally ready to lay down the damn track in Sonar with some canned ProAudio drums.

I’ve been struggling with getting my digital recordings to sound decent, especially the heavy guitar tone. I have pretty good tone from the amp and the room, but I cannot for the life of me get good tone to record. Worse yet here, I’m plugging into my Line 6 amp and using direct out from one of the amp models. It works… but it sounds pretty flat.

But here is the real kicker: I only have my shitty travel headphones with me here and predictably it sounds pretty weak between both the thin guitar recording and the headphones. The phones are optional noise canceling which I have off usually unless I am in fact on a plane or other noisy place.

So I listened to this stuff and accidentally flipped the switch into noise canceling mode – and MAN what a freaking difference. Whatever noise canceling does I want it on my guitar tone. It takes the wimpy winy sound and expands the shit out of it giving it the bottom end and bite that seems to be missing from the recording.

So the 64 million dollar question from the sound ignorant person is – what is it that noise canceling does and what is the equivalent guitar effect. <g> It’s almost like it’s Loudness on old stereos. It must be more than pure equalization as I can’t equalize the tone to anything close to that.

Anybody have any ideas?

Watch out for web.config Build Provider errors and Custom Controls on Toolbox

I just spent 20 minutes trying to figure out why I was unable to drop a custom control onto a Web Page in ASP.NET 2.0. I’ve been going back and forth between ASP.NET 2.0 beta installs and in one of my applications the same controls worked just fine, but in this app trying to drag the controls from the toolbox simply gave an error:

Control cannot be created because Visual Studio cannot find the control’s type in the control assembly

This error would lead you to believe that there’s something wrong with your control’s assembly or the control class itself.

Not so. This error apparently occurs whenever a control cannot be dropped and the reasons for this are many.

In my case the problem was that my Web.Config was invalid and had an invalid build provider config setting:

</buildProviders>

The appliesto=”Web” is no longer legal in post beta 2 builds and this caused the control to no longer work. Once I removed the appliesto – presto all is well.

My application clearly pointed me at that error – kudos for VS.NET to do that – but it’s not quite obvious while you’re working on your form that a Web.config setting can affect your control dropping ability.

Hopefully this will help somebody out and save you 20 minutes (then again if you are searching for it – it’s probably easily been 20 minutes so far <g>)…

Installed VS.NET 2005 Release Candidate

I took a risk yesterday and went ahead an installed the Release Candidate of Visual Studio .NET 2005 on my main machine after uninstalling Beta 2. I've been running on VPC with August CTP for a few weeks and even on VPC the performance and operation of VS.NET appeared to be much smoother than Beta 2. But it's VPC - I hate working in VPC other than testing. But I've been hesitant to blow away my Beta 2 install, since it's been stable and my past experiencing trying to uninstall VS and then reinstalling a new version haven't been the most successful resulting in machine re-installs most of the time.

Uninstalling and re-installing versions of Visual Studio in the past has been a major pain point, but I’m happy to report that following the uninstall directions resulted in a good install first try… Well, almost. My MSDN install didn’t let me see any dev topics, so I had to run Repair on that install, but after that all was well.

I haven’t spent much time with it yet, but on first look this is a much improved install. Most noticeable is the much improved performance of the IDE, which no longer seems to hang up and be stuck ‘thinking’ between clicks and keystrokes.

A number of things that had me quite a bit worried in the IDE was performance of Compilation of largish Web sites especially but it looks like the performance of the site compilation is now much quicker and up to what you’d expect (in fact faster than VS 2003). It also uses incremental compilation for the Web sites which wasn’t the case before and was the main reason for the slowness in Beta 2 I suspect.

I also noticed that debugging performance has gotten much better especially using the internal Web Server. Starting a project for the first time is much quicker and applications running seem to be much snappier as well.

The other good news is that other than the changes that occurred in ScriptCallbacks in ASP.NET in August CTP (the ICallbackEventHandler interface changed to two methods instead of one), the 3 Web apps and the 5 or so WinForm utility apps running Beta 2 all updated without any problems that I can tell so far. It’s going to take some retesting and checking before I can trust that assessment, but the code compiles and there are no errors in preliminary test runs.

I’m relieved to see the stability and performance improvements in VS.NET. Although I realize that Beta 2 was still a ways off from release there were A LOT of quirks in it and it was a bit scary to see so many loose ends that late in the game. The RC seems to be addressing most of these issues.

One thing that does seem to be broken is the Font configuration. A number of the font options don't seem to work right. I can't seem to get my string background set and some of the text options (like keywords) will not go bold properly (for presentation size). Setting fonts in VS.NET is a PITA anyway, but unless I'm missing some new options I cannot figure out how to get my main code view text to go bold...

Still, I’m stoked – now if I could only deploy the RC bits… grrr. I’m tired of waiting… <g>

IIS 6 Kernel Caching from an ISAPI Extension - eek!

Arrgh… After talking with some of the IIS team folks yesterday here at PDC about Kernel Caching in IIS, I thought it’d be nice to add this functionality to the Web Connection ISAPI extension. Kernel Caching uses a special ISAPI ‘function’ description HSE_REQ_VECTOR_SEND, which supports setting a few flags that are supposed to have IIS kick in cache the URL internally. What this does is basically cache a dynamic request similar to the way that a static file is cached in IIS.

This is server caching, not to be confused with browser or proxy caching. This means IIS is caching the file internally and when another hit to the same URL occurs the URL is served from the cache and not refreshed so the ISAPI extension is not called again until the Cache entry times out. You can set the duration of the cache via an Expires header that can be passed in optionally.

The benefit of this of course is that it takes the caching load completely out of the hands of the ISAPI extension, which in the case of Web Connection which is a fairly heavy weight COM server. It provides a performance improvement of an order of magnitude for pages that can truly be cached in this way. On my site this immediately brings a few things to mind, especially the various RSS feeds which are now cached application side.

Now, implementing this function is something I looked into a few months ago and gave up because of the horrible, horrible documentation on the Microsoft site. Yes, in hindsight I suppose it makes some sense, but even given that, without the help of a Microsoft dev today at PDC I probably never would have figured this out completely.

First things first. Kernel caching is cool but there are number of rules that need to be applied.

Requests must be under 255k
Actually the value for this is configurable, but there’s a stock value for the result message size. Kernel caching doesn’t kick in for larger files. The value is configurable in the registry (see KB article reference later).
Works only with IIS 6
This feature only works with IIS 6.0 (and possibly IIS 5.1 on XP SP2 – not sure though). Not a big deal except it’s hard to test exact behavior in a non-IIS 6 environment like developing in XP.
Requests require Last-modified header
In order for Kernel Caching to kick in a Last-modified and optionally an Expires header must be provided to IIS. These are used to manage the cache duration.
( Requests cannot have a query string )
This is a pretty big limitation for dynamic applications, but any page that contains query strings cannot be cached. This means Kernel caching requires either that you create a vanity URL, or simply don’t require a query string for the page. If a querystring is used there will still be browser caching (same user, same request might not hit the server) but not server side caching.
(the above is according to a KB article that describes limitations. In my own testing it looks like IIS 6 is caching query string requests just fine)

There are a boatload of more rules that a bit more obscure and not as likely to affect you, but you can find them in this KB Article here:

http://support.microsoft.com/?id=817445

To use Kernel Caching you use the ISAPI ServerSupportFunction() callback method with the HSE_REQ_VECTOR_SEND option. This option requires that you set up a request structure that breaks out the header and the body of the request and sends it as a single string to the ServerSupport function.

The following is a C++ function that takes an full HTTP response including HTTP headers as input splits them up, sets up the various structures required and then calls ServerSupportFunction for caching:

CacheOutput

Caches output for a full request string in the IIS Kernel Cache.

Assumes you have already made sure that:

Header is included in the request

includes Last-Modified and Expires headers

BOOL CacheOutput(EXTENSION_CONTROL_BLOCK *pEcb,char *lpOutput,DWORD cbSize)

{

HSE_RESPONSE_VECTOR vec;

HSE_VECTOR_ELEMENT element;

DWORD HeaderSize = 0;

char *strHeader;

// *** find end of header

char *Content = strstr((const char *) lpOutput,"\r\n\r\n");

*Content=0; // null terminate

//// *** if we have no header end just send it as part of request

//// *** Otherwise split it out with

strHeader = new char[ strlen(lpOutput) + 1];

strHeader[0] = 0;

strcpy(strHeader,lpOutput);

strcat(strHeader,"\r\n\r\n");

Content = Content + 4; // Skip over header breaks

HeaderSize = strlen( strHeader ) ;

element.ElementType = HSE_VECTOR_ELEMENT_TYPE_MEMORY_BUFFER;

element.cbOffset = 0;

element.cbSize = cbSize-HeaderSize;

element.pvContext = Content;

vec.pszHeaders = strHeader;

vec.lpElementArray = &element;

vec.nElementCount = 1;

vec.pszStatus = "200 OK";

vec.dwFlags = HSE_IO_FINAL_SEND | HSE_IO_CACHE_RESPONSE | HSE_IO_SEND_HEADERS;

BOOL Result = pEcb->ServerSupportFunction(pEcb,HSE_REQ_VECTOR_SEND,&vec,NULL,NULL);

delete(strHeader);

return TRUE;

}

This function takes a full response string as input and it assumes the content is prefiltered and contains an embedded http header. Typical input looks like this:

HTTP/1.1 200 OK

Content-type: text/html

P3P: CP="ALL CRA TAA OWW IND PHY ONL"

Last-Modified: Fri, 16 Sep 2005 04:13:52 GMT

Expires: Fri, 16 Sep 2005 04:23:52 GMT

… more HTML

which is a typical response that Web Connection might generate to force caching. In this case the cache would be 10 minutes. Notice the Last-Modifed and Expires header, which the Web Connection ISAPI DLL uses as a trigger (in addition to an IIS 6 check) to fire the above method.

Note in the code above that you have to make sure to split the HTTP headers off the main content. Make sure that the Headers contain the two trailing CRLFs or else IIS will not interpret the headers and simply write them out as is. That threw me for a loop as I assumed IIS would accept the headers without the trailing CRLFs. Once I added them in the code started caching properly.

My mainline ISAPI code then checks for a set of conditions (IIS version, Content Length and headers), which if verified cause the code to branch and call the CacheOutput method instead. This is some internal stuff here, but it should give you an idea of what to check for:

// *** If we use Caching - use Vector Send to send the whole file

// Works only IIS 6.0

if( gnServerMode > 11 && ContentLength < 255000 &&

stristr(lpHeader,"last-modified:") &&

stristr(lpHeader,"expires:") )

{

DWORD Result = 0;

try

{

char *OutputBinary = (char *) new char[ ContentLength + 4 ];

ReadFromFile(pParam->szOutputFileName,OutputBinary,&ContentLength);

OutputBinary[ContentLength] = 0; // null terminate

Result = CacheOutput(ecb,OutputBinary,ContentLength);

delete(OutputBinary);

}

catch(...)

{

StandardPage("An error occurred","The application failed to write Cached Output to the Cache Store.",

ecb,"CacheOutputFailure");

Result = FALSE;

}

return Result;

}

This is very cool and I have a number of places where this functionality can be applied right away, so I’m stoked.

Hopefully this will help make life a little easier for anybody else who needs to use HSE_REQ_VECTOR_SEND and Kernel Caching…

Note that for the moment I didn't mess around with Cache invalidation API which is also available.

My ASP.NET Script Callbacks Article Part 1 went live on ASP Today today

The article covers the good and the bad of this technology, which is getting overshadowed by what Atlas promises much further down the road. However, Script Callbacks are built into ASP.NET 2.0 in the box and are going to be available as soon as .NET 2.0 ships.

Check it out at:

My ASP.NET 2.0 Script Callbacks article Part 1 went live today on the ASP TODAY site today. This two part article series is a lengthy look at the first AJAX like functionality Microsoft is shipping in ASP.NET 2.0 and what you can do with it. While a stop gap technology between what’s available now and what’s coming – especially in light of the power of what Atlas promises in the future – it’s technology that’s going to be in the box and usable much sooner.

Check it out at:

http://www.asptoday.com/Content.aspx?id=2381

The ASP Today site is a registration site so you need to register and I believe back content is only for subscribers.