I wanted to blog about it for a while, but i just found one of the things i wrote on the longhorn newsgroups (yes, I will return to newsgroups starting next week). Reproduced here. Parts I edited are in between [].

As you probably can guess, it is far from being THAT simple, and would in fact require a common top technology from which targetted content could be deployed. Asp.net surely enough have the flexibility to provide that, so does Avalon. And I know someone very intelligent on the net likes this idea, so it validates my point.

Sebastien:
Also note that because of the custom device renderers included in asp.net, it [should] be possible to serve nearly transparently XAML data from an asp.net page.

Chris Sells [MSFT] (VIP):
That sounds interesting, Sebastien. Care to elaborate?

Sebastien:

Well, I didn't investigate the feasibility fully yet, which should only be next week, but:

ASP.net support the idea of web controls using device renderers to intelligently render content to any format. As it goes, it should be possible to target completely different languages, like SVG or XAML, from the control. I could even go as far as saying there's nothing preventing, AFAIK, pure code being generated, but that would be a pain to code.

Now, using this adapter, it is possible to target XAML, and provide a rich XAML based rendering technology on top of the ASP.net controls, and effectively switch automatically from HTML to XAML rendering.

Now there are a few limitations: 1. Internet exlorer doesn't compile on the fly. This should definitly be resolved by using SSE, compile on run time on the client side and analyze security on the fly, for embed code. This pauses the same problem as scripting languages. IMO, the correct way to do it would be either of the following:

XAML is generated from the ASP.net controls, but has a contract with the code behind that can be pre compiled by the developer and loaded in real time over the wire for execution. SSE plays its role there too.

Avalon/ASP.net compatible controls, where the control can either work on the server side like asp.net controls, providing for an adapter based system to render to cHTML, xHTML, WML, etc, and that can be downloaded in real time as compiled XAML, executed on the client to provide for more avalon like features (3d, etc). What I'm talking about here is a full merge between web based and windows based controls, for the goal of defining one interface, and have it execute seemlessly as a compiled application, a web application and an http exe. Without the associated problems.

2. Internet explorer doesn't have, as of now, integrated namespace dependent rendering support. What I'm talking about is what I told Don Box a few months / weeks ago: Instead of parsing XML data to simply initialize the object model, provide for different XAML controls based on the namespace. I'm getting confusing there. let's say (pseudo xml):

    
Share
    
    

    


    

    

    

    

    

    
    

    


      
      

        
Ads