This post originated from an RSS feed registered with .NET Buzz
by Tim Sneath.
Original Post: Reflections on Tuesday
Feed Title: Tim Sneath's Blog
Feed URL: /msdnerror.htm?aspxerrorpath=/tims/Rss.aspx
Feed Description: Random mumblings on Microsoft, .NET, and other topics.
One of the most significant things I heard today was a throwaway comment made by Scott
Guthrie in his excellent ASP.NET
2.0 session this afternoon. It had nothing much to do with the session itself
and perhaps isn't even implemented yet as a feature, but it immediately struck me
as having a great impact for web applications moving forward. The comment was this:
in the Longhorn timeframe, ASP.NET will implement a XAML rendering adapter as
part of the adaptive UI.
There are two reasons why this could be hugely valuable. Firstly, it provides a migration
strategy for ASP.NET developers moving forward. If you're thinking of undertaking
a major ASP.NET development in the next twelve months, it will be a great relief to
know that this work won't be wasted or rendered obsolete by the end of 2005. Secondly,
this helps make the case for the statement that I made in yesterday's
reflections - that it's possible to imagine an Internet world where the primary
way to experience a company's site is via Avalon, with HTML there as a backup, downgraded
experience. If you can use ASP.NET to produce both, then there's no reason why this
shouldn't be the case. Not
everyone's convinced, though...
Eric's
talk this morning was great - particularly because Whidbey is much closer to becoming
reality than Longhorn is. There are tons of new features that will help establish
.NET as a mature platform for building applications of all shapes and sizes. I can
see the "My" class hierarchy being popular for the kinds of smaller-scale VB developers
that have been alienated by the complexity of .NET, and the arrival of .NET on devices
like the Smartphone can only help extend the capabilities of this kind of platform.
Finally, the WinFS
session today highlighted a fairly important shift in the way storage will operate
in the future. Most pressing in my mind is the architectural choices that this brings
up - when will it be appropriate for my application to create WinFS items, versus
a database record or a conventional file? One of the speakers apparently suggested
that in a personal finance application, transaction records would be worthy candidates
for storage as WinFS items. I don't buy that yet - unless there's a fair quantity
of document-style data, that kind of object would seem best placed as a database record
to me, but these are early days and perhaps I'll change my mind as I dig deeper into
WinFS.
Previous Topic
