If you don’t know Don Box or have ever been in a room with him I can only think of a few ways to describe:

– Don Box is the eloquent mad genius of Microsoft
– Don Box has a permenantly attached 150 gallon kool-aid container attached to his back, which is dispense via two WebService enabled super soakers.

Don did his same flashy intro as last year, except that he used scheme this year instead of notepad. He asks the audience for a list of questions and topics. Here’s his list of topics he was asked to cover:

1. EMCA-izing indigo
2. What is this shit?
3. BRE vs. DSLs
4. WTF – WTF?
5. Future of the ESB
6. What could suck more than C++
7. Java and Indigo
8. Code bloat and performance
9. Microsoft vs. SOAP
10. Interop
11. Canada vs. Microsoft
12. Indigo and reach (small devices etc.)
13. How would I simplify indigo and its components
14. Why did we build Indigo?
15. Disclose trade secrets (tell us what is next)
16. WS-* SOAP REST POX (plain old XML) et al
17. Why we use less CLR in Longhorn than we thought we would (my versioning question about data, characteristics, behavior, etc.)
18. Which sucks more CORBA or WS-*
19. Crackpot guidance from a random guy you don’t know nor can hold accountable (what should we use instead of CORBA or WS-*)

I could olnly write down a few things he said, but the majority of his message was WS*.

1. No plan to do this for WinFX.
2. Don explained all the acronyms of WinFX and all the other stuff they are working on, but I won’t cover those, just google for them.
3. Don had some very interesting stuff to say about DSLs and the death of the Object-Oriented coding style as well as for-loops. His contention is that when you get 7000 folks writing classes and for-loops you always get a huge complex pile of code. His contention is that DSLs are ideal for most business processes, workflow and the like. Of course I’m a versioning nut and really wanted to know what his thoughts were on versioning of DSLs and legacy DSL code. My contention is that DSLs in the hands of mortals are more dangerous than classes and for-loops because a bad version of a DSL can break all legacy code unless the DSL is intrinsicly versioned, which again is difficult for mere mortals. I don’t claim to know the solution to the versioning problem, but I know that DSLs must be written by those who are capable, like the language engineers at Microsoft, IBM and Sun and not allowed to flow freely from any old software shop. BRE is such a DSL it seems, but I don’t know if Don’s team has tackled the versioning problem with BRE.
4. Missed this one
5. Don’s comments on ESB started simple with a notion of normalizing the messaging stack and how they surface to the developer (WCF). Step one is a common abstraction for a message inside a Windows machine. This abstraction is called Message and is a type that can be handled by the developer. To me this is extremely similar to SDO. Second step is a common way to handle pub/sub and queuing, events, etc. I followed up with a question on SDO and SCA and how it compares with this Microsoft Message abstraction and Indigo. Don’s response was, “our messaging model is XML” and inside the machine SDO or Message are roughly equivalent because they are not wire models. I definitely agree on this but also using a non-standard API such as their Message API does make code less portable, but of course C# and VB currently aren’t totally portable. It would only boil down to Java and Python inside and outside the CLR.
6. Missed this one
7, 10, 14. Don’s always direct when you start talking about Java. He always says that Java is probably the largest reason they wrote Indigo. There is a ton of Java out there and working nicely with it is paramount. I doubt anyone would disagree with this.
8-9. Missed these
10. Same as #7
11-13. Missed these
15. One could only guess what’s inside Don’s head, I’d rather stay out of there and wait until he’s distilled things into something understandable.
16. Don’s comments about WS* and all the other XML stuff out there was interesting and he’s pretty much correct. Since XML is so open and accessibl and readable, it caused an enormous number of developers to reject it because they could see the SOAP overhead (minimal) and anything else in the document that they wouldn’t have put there if they were writing everything by hand. And then most of them went off and did just that via REST, XML-RPC, POX, etc. He also talked briefly about good ol’ binary protocols which were impossible for most developers to parse, making them excellent because then only the really anal retentive folks would turn up their noses because they would have spent the time to go byte by byte through a message to see what’s inside (or read the spec line by line). They would then reject it because they could think of a simpler or more concise and complex format if they were coding everything by hand and then go forth and do so. But the number of these people is so small that the technology would stick much easier. With this and the fact that IAP uses FastInfoset, I had to ask about FI and Fast WebServices. Don’s excellent at being Microsoft and waiting on this one like the rest of the world. He said that he wanted to see what customers wanted and what the industry asked for before going full force on FI. I personally think this is bogus, mostly because we all know that binary is better and Don know this as well. I don’t care if it’s FI or MSWSBF (Microsoft WebService Binary Format – I made this up since Microsoft loves acronyms), I just want a something I can build on and not have die a few months later.
17. This is definitely a Pontarelli question about versioning. Don mentioned that CLR doesn’t version easily and that in order to have some type of versioning, regardless of how poor it might be – which by the way is no more poor than Sun’s or anyone elses solution, they had to use less of the CLR than they had originally planned. Don’s final comments after I poked and prodded again pretty much concluded that Microsoft is still working on the versioning problem like everyone else and haven’t figured it out yet. I asked a lot of the same versioning questions last year and last year I think they were a bit scared of their lack of progress and said very little about what they had accomplished. A few engineers even made it sound like something really cool was on the horizon. I’m glad to hear from Don this year that they were no further ahead instead of some cheesy non-response that gets peoples hopes up. Honesty in this arena is best because eventually you have to show something and if you got nothing you look worse than if you’d just said you got nothing but are really investing in trying to get something.
18. CORBA but not by much
19. No clue I checked out after versioning.