Longhorn, what does everyone think?

[JDeats]

Just spent some time browsing around here:
http://msdn.microsoft.com/Longhorn/

I can see the benefits from WinFS (as long as we tag all in-coming
data this should be nice, tagging everything could be a tedious
process though) but I haven't been able to pick up the practical
advantages of XAML. From my assessment, XAML will provide separation
of UI logic from business rules/procedures for applications. It seems
like an HTML of sorts for desktop application UI. But where are the
big advantages of designing desktop applications this way? It may
provide a nifty way to create UI-"skins" to provide a custom
experience for different users, but that can do as much harm as good,
it's not revolutionary.

I can think of some disadvantages to this approach, namely all the UI
logic has to processed at run-time (interpreted) and a generic
container application has to exist to marshal between the presentation
and the procedure code. Even if this marshall process is part of the
core OS, it still seems like needless overhead without any
clear-advantages.

Also the Longhorn UI guidelines are nothing to wow over, there's a new
side-docking bar that we can use to provide small bits of information
at all times, it's going to get cluttered quickly.

I don't know about most of you, but with all the processing power or
modern PCs I was hoping for something more radical (how about a 3D
User Interface for the OS), am I alone here?

[Christoph Nahr]

On Fri, 31 Oct 2003 00:51:05 GMT, "Daniel O'Connell"
<[e-mail]> wrote:

No, not in any serious way. A new rendering engine is an OS feature, not a
framework feature. Just because its written for .NET doesn't mean its part
of the framework.

By the way, will it be possible to use that nifty XAML format for GUI
elements on older Windows versions, as long as the proper .NET
Framework version is installed? Minus all the new rendering stuff
like playing videos in the background -- just placing controls etc.
--
http://www.kynosarges.de

[Daniel O'Connell]

That I don't know, but if MS doesn't provide a way, I suspect someone will
write a XAML-to-Winform converter that generates a winform that is as close
as possible to the Avalon rendered XAML file, perhaps without all the nice
automatic flow-layout features. Time will tell on that one I suppose.

It would be nice tho, wouldn't it?
"Christoph Nahr" <ch************ @kynosarges.de> wrote in message
news:mm******** *************** *********@4ax.c om...

On Fri, 31 Oct 2003 00:51:05 GMT, "Daniel O'Connell"
<[e-mail]> wrote:

No, not in any serious way. A new rendering engine is an OS feature, not aframework feature. Just because its written for .NET doesn't mean its partof the framework.

By the way, will it be possible to use that nifty XAML format for GUI
elements on older Windows versions, as long as the proper .NET
Framework version is installed? Minus all the new rendering stuff
like playing videos in the background -- just placing controls etc.
--
http://www.kynosarges.de

[JDeats]

"Alvin Bruney" <vapordan_spam_ me_not@hotmail_ no_spamhotmail. com> wrote in message news:<OF******* *******@tk2msft ngp13.phx.gbl>. ..

So you play a video in

the background of you form, so all the controls on the form are now
vector based (humm wonder where Microsoft got that idea..), it's cool,
but it's not mind blowing amazing. Couldn't
Think about it. Can you do that today how it was demo'd? Transparently?
Freely mixing form elements? Think about doing it today and how much effort
it would take. Now think about whipping it up in a couple seconds with a
couple lines of code.

....

Alvin,

We'll it's a vector based rendering engine for Forms that makes use of
DirectX features (such as real-time video playback). Having worked
with DirectX and Macromedia's Flash technology this is a hard thing to
get excited about. It's not revolutionary, but it is telling in that
it shows Microsoft is more or less building a Flash counterpart into
their core OS product. Since the IE version that ships with Longhorn
will also support XAML this has more potential for web based apps than
rich-client and the ability to do vector based graphics without
third-party tools will be nice.

Sorry.
If that doesn't amaze you, nothing will.

--

Not true, even if you're not a game player, check out Idsoftware's
upcoming Doom III, it's an example of revolutionary technology that
amazes me.

[JDeats]

"Daniel O'Connell" <[e-mail]> wrote in message news:<Zliob.653 34$Tr4.175910@a ttbi_s03>...

"JDeats" <je****@pdq.net > wrote in message
news:b0******** *************** ***@posting.goo gle.com...

Okay, I watched the video. The demonstration of XAML (oddly pronounced
zam-el) was kind of neat, but "amazing", nope. So you play a video in
the background of you form, so all the controls on the form are now
vector based (humm wonder where Microsoft got that idea..), it's cool,
but it's not mind blowing amazing. Couldn't these type of features
just as easily have been part of the new .NET Framework? Why do they
require OS release to be possible.

No, not in any serious way. A new rendering engine is an OS feature, not a
framework feature. Just because its written for .NET doesn't mean its part
of the framework.

Well that depends. A rendering engine can sit on top of an OS quite
easily actually. From that demo and from what I've seen of XAML, it's
an XML language that defines user interface elements, it supports
vector based graphics and DirectX features. This is nice and all, but
Macromedia's Flash technology gives you the same features now. I don't
know if you can use XML to define your Flash applications (it's
probably still a binary format), so that is a big difference. But the
point in that reference is that if I wanted to create an application
like that I could. I could use DirectX 9 and build a rendering engine
that provides an XML parser, etc.. to do this sort of thing, it could
be written, it wouldn't be easy, but it could be done.

The Indigo demo was boring and uninspiring. What's special about that,
I could create a generic messaging class in C# in a days worth of work
or less and accomplish the same type of thing, again why is this a
core OS feature? It seems like it should just be part of the next
incarnation of the .NET Framework.

Could you design one that supports SOAP, SOAP1.2, Xml Serialization and all
the other bits that can travel over any communication mechanism in as many
days?
As for why its an OS component...tha t I can't say, except perhaps because ti
was written for Longhorn and is used in Longhorn.

No, I guess there's more to Indigo than I thought.

WinFS is by far the coolest thing about Longhorn, but I still have a
lot of unanswered questions. For example, let's say running on
Longhorn I have an MSAccess database file, an Excel file and an XML
file, all in different folders. If WinFS archives all files inside a
SQL Server style dbase how much power will it give me in querys?

Say the MSAccess file has a table called "Users" that has ID and Name
columns, the Excel spreadsheet has an ID and Name column and the XML
file has a similar structure with ID and Name nodes. Would it be
possible to perform a SQL JOIN on all three files based on ID and get
back a result set? When I think of everything in the file system as a
database object, that's the kind of power I'd be expecting.

I don't know for sure if this is possible and I don't know if there really
is any point to that, in 98% of usage cases this would be extra code for no
use, and I bet you probably wouldn't even use it yourself.

The ability to query data from multiple non traditional sources would
be very useful.

That is what a
database is for and you could do it via ADO.NET easily(WinFS can be accessed
via ADO.NET). However, it has alot to do with the objects and schemas
designed into WinFS, there is NO way the system could understand every
possible file placed on it, and I suspect it would be more a matter of how
the schema works internally than WinFS itself.

Of course it couldn't understand every type of file, but an interface
standard could be adopted, for example a standard header for binary
files that points to a managed .DLL that would provide an interface
for the OS to understand how to get to that data. A few generic
handlers based on extension (e.g. .xml and ascii) could be provided
for non-binary types. If no header were present then the indexing
system could just ignore the contents of the file. Since WinFS is
based on Yukon I guess this would be something the core database would
have to support.