Description
 


Welcome to my Blogroll
Important statements
Cool Tools
Our stuff
Current Collaborators
True Nerds to know
Open Technologies
In Rotation
Occasionally
Resources






October 2003
Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Sep   Nov



Click here to visit the Radio UserLand website.

Subscribe to "Marc's Voice" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.

Marc's Voice
Home LANs + Broadband + Devices

Wednesday, October 29, 2003
Avalon isn't about Web/GUI convergence.

  Tuesday, October 28, 2003 

Avalon isn't about Web/GUI convergence

Edwin Khodabakchian echoes what seems to be a common -- but I think incorrect -- perception that XAML, the XUL-like layout language revealed this week to be a building block of Longhorn's Avalon presentation subsystem, heralds some kind of Web/GUI convergence:

We had prototypes and concepts at Netscape that were very close to what Microsoft is starting to promote with Avalon. One the positive side, it is great to see HTML, XML, CSS and SVG become the foundation of UI development within windows. [Organic BPEL]

My understanding, based on a demo I saw last week, is that although XAML is indeed an XML dialect, it has nothing to do with HTML, CSS, or SVG. It's true that the Avalon presentation engine is Web-like, or to be more precise ASP.NET-like in its separation of layout markup and "code-behind." But it builds no bridges to pre-Avalon clients. The foundation of Avalon's vector-based UI, for example, is Direct3D. I asked whether SVG -- an obviously relevant Web standard -- would be a preferred (or at least a supported) interface to Direct3D, and was told that it would not.

Here, from the newly-hatched Longhorn Developer Center, is another statement which implies a convergence that I don't see in the cards:

Avalon and XAML represent a departure from Windows-based application programming of the past. In many ways, designing your application's UI will be easier than it used to be and deploying it will be a snap. With a lightweight XAML markup for UI definition, Longhorn-based applications are the obvious next step in the convergence of the Web and desktop programming models, combining the best of both approaches. [Longhorn Developer Center: Code Name Avalon: Create Real Apps Using New Code and Markup Model]
To my way of thinking, you don't have "the best of both approaches" unless you have a ubiquitous client. As Jeremy Allaire pointed out the other day, Flash is making a serious effort along these lines, and has -- in Laszlo and the forthcoming Royale -- its own XML-based layout techniques. I've also mentioned Mozilla's cross-platform technique, XUL. Now Microsoft is pitching a Windows-only UI renderer that targets 2006-era desktops and notebooks, while allowing MSIE to stagnate. I can see how and why they arrived at this strategy, but it doesn't seem to be the kind of Web/GUI convergence I'm looking for.

 

[Jon's Radio]

A couple of points about this post:

1) Laszlo is an XML technology - while Royale is Flash technology.

2) Jon's right about XAML - it goes around CSS and HTML - like only Microsoft can.  And it certainly IS in the 2006 timeframe.

But Laszlo is ready to go NOW.  They're about to head into their v 2.0, whilke Royale is not even in beta yet.

Laszlo is VERY much like Avalon, enabling developers to build entire UIs - with barely any scriupted code.  But the KEY difference between Laszlo and Royale - is that while Laszlo spits of .swf today, it will be able to spit out Avalon tomorrow.

So smart developers to build on top of Laszlo today, utilize the installed base of Flash but THEN be able to easily migrate their code to Avalon later.  While Rpoyale users will be locked into .swf.

 Don Box | Longhorn | Microsoft 

I'm reposting Dana's article- as I actually havea different angleon this - and I'm using this as a launching pad.

I actually think Bill's biggest problem has always been his employees.  Their arrogance and incompetance is why Bill can never retire....

Anyway - back to Longhorn and the future.  Looking at Indigo - I really think that Microsoft thinks they've won.  There's no reason to hide behind or play games with inter-operability and compatibility anymore. Indigo REALLY seems open and fully capable of meshing into anything, whether it's their own legacy technology or others.

Don Box appears to be a real hero.

Microsoft's Biggest Problem.

Microsoft's Biggest Problem

Microsoft's biggest problem is that it has become too political.

This is partly the fault of the government. The antitrust case greatly increased the number of lawyers and PR people working for the company. Questions involving the DMCA and security have been driven by government demands, not customers.

This was apparent in looking at the company's recent developer conference. Longhorn is a big bet, but it's the kind of bet a smaller company should be making. Decisions like the one to kill Windows Messenger in favor of a firewall default are inherently driven by politics, not customers. All of its stupid codenames are created by bureaucrats with too much time on their hands -- fewer codenames, more code please. And the continuing failures of its PDAs and smartphones are driven by its continuing demand to embrace and extend than making anyone's life easier.

These are not the kinds of decisions an entrepreneurial company takes, because they weren't made in an entrepreneurial way. These are government decisions made with a bureaucratic process.

Partly this is a function of the company's size. There is one product line, thus one bottleneck through which all good ideas must pass. The process becomes inherently political.

But founder Bill Gates must also take some blame. He has defined his career as a fight for control of the growing industry's direction. There are two important words in the previous sentence, fight and control. Gates thinks the key is control. It's not. It's fight.

Maintaining control is a political struggle. Fighting, in the case of business, is a market struggle. There is a big difference.

When control is the key, you're choosing one alternative among many, then putting all your eggs in one basket. When you're fighting for business, you follow demand -- you try to figure out what customers want and give it to them, even if that means giving them alternatives.

The easiest way for Microsoft to eliminate its political problems would be to break up. That was the ultimate aim of the antitrust suit, which Microsoft won.

But was it a pyrrhic victory? I think so.

Back in 1911 John D. Rockefeller was playing golf with a friend, when word came in that the Supreme Court had ruled a break-up of his Standard Oil trust must proceed. Informed of the news, Rockefeller calmly holed his putt and offered one piece of advice -- "buy Standard." Those who took his advice prospered. They wound up holding shares in a large number of highly-competitive, aggressive companies. The same thing happened many decades later when AT&T was broken up. (The massive Worldcom fraud cost AT&T shareholders more than anyone else, but they would still hold stock in three regional Bells, several other companies, and cash from their sale to Qwest.)

The point is that monopolies engage in political struggles, which makes them inefficient. Whether those struggles are against the government, or internal -- between and within product groups -- doesn't matter. What matters is that energy and talent are being wasted.

There may be ways for Microsoft to re-organize so as to reduce its political conflicts. Those ways should be sought. And when they're implemented, you will have created ready fault lines along which the company could be broken up, once the inefficiency of fighting the government becomes obvious.

In other words, to solve the problem of politics, break up the company. Break it up symbolically now, even if you continue to resist breaking it up for real.

Then, find some entrepreneurs and give them control of the pieces. Bureaucrats are fine, in their place. But their place is in the engine room, not on the bridge.

Dana Blankenhorn  [Corante: Moore's Lore]

MONO at PDC.

MONO at PDC

Miguel held another of his impromptu talks at PDC today. He seems excited about Indigo - having it working within mono before whidbey, and avalon later using cairo gfx - and about the way that Mono is moving forward as a .NET enabled platform. Yay! Open Source .NET :)

He talks about his mono conf and also about some of the other cool things happening. Result? Mono rocks :)

[Home is where the heart is. Apparently.]

Watching Miguel last nightwas inspiring.  I agree with him - Indigo is REALLY good news!

 Microsoft | PDC | RDF 

I can't possibly blog every session or highlight all the stuff I'm learning here at the PDC - but needless to say my head is spinning.

These folks have come up with their own 'triples' - their own subject-predicate-object sceanrio. It's part of their WinFS file system (formerly known as Cairo.)  They have no idea that this is identical to rdf's approach - and they NEVER mention the S word (Semantic) - but they DO grok that having RELATIONSHIPS baked into the file system - is a good thing.  They also have synchronizatioon and compositing baked in - as well.

Synchronization adaptors is the method they provide for allowing US to create our own sync sceanrios.  All of these technologies I've been talking about - are shown in real live demo - usually by typing in less than 20 lines of XAML or C# code into Visual Studio.  Right in front of our eyes: IM is added (one line), contacts are included (5 lines), documents are synched (10 lines) or even UI's animated (4 lines.)

So this is VERY powerful stuff, being committed to by the world's largest software company - and whether we like it or not - it's at least PART of our future.  WinFS id much more thsan just an o-o file system. It has Documents(files, media, etc.) - Messages (email, IM, fax, confercning) - Contacts (people, orgs, groups and households) ALL as first order objects.

In others words - they're built into the system - at all levels.  EVERY app and service can access shared documents, messages or contacts. Any of these items can have a relationships to another and kept in sync. It's heavy!

 Longhorn | PDC 

Two types of item sets:

   - dynamic sets - which are defined implictly by querries - these are search results and logical groupings - based upon properties of an item

   - static sets - which are explicit relationships between ietms - these are folders (or containers) - and they don't change

Needless to say this is the object oriented, virtual file system.  It goes across-volumes and across-machines.  Key ingreident for the digital lifestyle.

 Jeremy Allaire | Microsoft | Mozilla | PDC | XUL 
XAML vs XUL.

An Avalon engineer provides a brief discussion comparing XAML to XUL.  What it more or less comes down to is that XAML manifests the complete Windows API set, whereas XUL manifests the Mozilla/DOM API set.

[Jeremy Allaire's Radio]

So the question is -"who would you rather place a bet on - Microsoft or teh Open Source community?"

THIS is the question - dear readers.  I myself say - both :-)


Updated: 11/1/2003; 10:17:29 PM.