Pete Lacey on Religion

Don,

Is 'Future Proof' ever the right way to build something? Wouldn't it have been better to just build and use more real-life distributed apps at Microsoft and then see what was most useful to keep and mature?

A danger of product groups is that they miss the essence of what needs to get done, they convince themselves that 'one more extensibility' feature is not making them 'pick a side'.

Well, it never works that way I'm afraid - the usages you picture for 1.0 spread throughout the teams like a gospel, even if it wasn't intended like that. SOAP was the canonical example for Indigo.

The 'platform' building dilutes away with every edge-case requirement you incorporate, until only the very basic is left, and that's often just a replication of something already on the stack.

You miss the usage 'sweet spot' because the very thing that makes it extensible is the tiniest amount of extra complexity that turns people away. It hardly takes anything to do this. Now, this isn't particularly fair, but getting a platform to be used is not always about the bits but about the people and/or place in time.

While your next rev may be JSON supported (or extended to show this), the moral of the story is that everyone else will have moved on to something else by then (my money is on a CSV/EBCDIC using wet-string combo). You'll be stuck in another release-wave quagmire and JSON maybe deeply unfashionable by then.

The Generic Platform attitude is a throw-back to engineering to a Windows captured market, and will either be (a) ignored by those with an alternative or (b) defended by religion rather than its usefulness. Today the alternatives have got their act together better than ever before. They'll building frameworks specifically for a purpose because they actually build applications they need - the reuse was a side-effect and not the mantra.

Rutherford said 'All science is either physics or stamp collecting' and from where I sit I see Indigo as a big stamp collecting exercise that got killed the moment the politics made it ride with the 'Vista Wave'. To do something new you have to *write good apps* that people love and use, and not try to predict what they will need in the future or by asking others for their 'requirements'. USER32/OLE was a one-off in history - let's stop trying to recreate those times...

Indigo may be used because there might not be alternatives shipped on that DVD, but it might not be loved. It may fail due to why SOAP is now struggling - because it was built on speculation of what many clever people *thought* they needed rather than what they *knew* they needed.

Built real apps - solve peoples problems and lets all come down from orbit...

I would be interested in what you think of the article penned by CORBA legend Steve Vinoski stating that REST and SOA are incompatible. It is linked from this InfoQ thread where we have been arguing about it:):

http://www.infoq.com/news/2007/01/vinoski-on-rest

David,

So what are you suggesting Microsoft should do? Sit around and jump on the next bandwagon wherever it should arise?

Part of the problem as I see it: MS largely invents SOAP. A vocal segment of the IT Community resents MS. Therefore they resent SOAP, web services etc.

The 'Generic Platform' has (if I understood your meaning of the term) stood Microsoft pretty well over the years. This ideal arguably underpinned the success of many MS products (COM, OleDB). OLE itself was a remarkably innovative technology and a very necessary step in MS's evolution.

"Wouldn't it have been better to just build and use more real-life distributed apps at Microsoft and then see what was most useful to keep and mature?". David, have you heard of the term 'dog-fooding'? Are you not aware that MS uses the majority (if not all) of their products in-house? Have you heard of products such as MS Exchange and Sharepoint?

I am sure that SOAP technology is already used in a myriad of ways within windows, such as the current software installation platform.

MS does build real apps, and those apps are based on solid generic infrastructure. WCF will only continue that trend, and be more accessible by your average progammer - unlike OLE and COM.

"With Indigo, we made a bet that the world wanted to integrate software based on exchanging data rather than sharing runtimes. That was the premise. Period."

if this was the case why is the data shared in a hierarchical format rather than a relational format?

Maybe WCF is more future-proof in some respects, but it sure isn't "past-proof". I got quite lost figuring out how to re-plumb a POX/HHTP app written using WSE 3.0 to use WCF. It didn't help to have "WCF Hands On!" tell me I have an XML Fetish (pp. 75-76) just because I want a couple of useful XSD constructs in my data contracts that were awkward to implement using a pile of C# attributes. That's hubris.

Anyway, I do think the programming model -- which I agree had to become unified -- is hard to absorb, especially for metadata-driven scenarios (dynamic types in data contracts) or other situations where .NET remoting was not considered first.

Maybe Microsoft could put some more time into building working examples that cover the capabilities and objectives of the frameworks that WCF appears to supercede (WSE, ASP.NET) and maybe some interesting programming models that got no attention during the Indigo era (Fabrique, whatever).