Remembering the Future

. . . Oddly, Redmond seems blinded to the reality of the new Web operating system, where technologies such as RSS are pushing the marketplace toward small XML fragments called micro-content and away from bulky Word documents. . . . Luckily for Redmond, office suite competitors such as Lotus and Novell imploded at the same time. Even now, Sun's OpenOffice has cloned the Microsoft hairball rather than producing micro-content objects that could be stitched together to create the same kind of rich compound documents. In a micro-content world, business documents are broken down into their constituent elements: notification, transaction, context, priority and lifetime. IM traffic, Weblog posts, breaking news, appointments, alerts and good old e-mail comprise a dominant percentage of micro-content traffic. Managing the real-time flow of information becomes Job One, followed closely by archiving and publishing snapshots of the data as "documents." The traditional productivity applications become rendering engines for various end-stage documents. Word produces spell-checked, formatted pages; Excel produces reports, charts and graphs; PowerPoint produces presentations. In its current incarnation, Outlook renders messages. FrontPage—well, FrontPage is being sunsetted by Weblog-authoring tools. To be sure, Microsoft can take comfort in its strategy of waiting for the competition to do the R&D and then swooping in when the market is primed. Micro-content authoring tools are in their infancy, held back by the lack of resources in mom-and-pop RSS aggregator shops. . . . As RSS information routers reach the critical mass of persistent, searchable storage, feed-tunable preferences, embedded browser rendering, and attention data mining, the motivation to store data in licensed document silos will flatline. Remember: Microsoft is competing in the micro-content space with the one non-renewable resource: time. Nowhere in the real-time space does it have dominant market share—not in IM, not in RSS, not in search. If it places its chips on Word, it's competing not just against micro-content, but against its own installed base. There are some signs that Gates gets it: hiring Wiki inventor Ward Cunningham, incorporating some OneNote technology into the next Mac Office release and even floating a rumor that he will start an internal blog. But Longhorn still reminds me of the Las Vegas skyline, where objects appear a lot closer than they really are.

Now I've gone on endlessly about the complexity and short-comings of XForms: Web Services vs. Internet Services,HTTP and HTML, Sans DELETE, andXHTML + XForms + XLink = Xanadu.

Web Forms 2.0, edited by Opera's own Ian Hickson, is a breath of fresh air. Instead of trying to completely revolutionize HTML forms, it takes an incremental approach, building on an already stable base, fixing common problems (like the fact that forms can only do GET and POST, which in my opinion is a bug of the HTML specifications), and adding new features in a way that is backward compatible that strike a good 80/20 balance (a new mime-type for form submission of application/x-www-form+xml).

It starts with this completely sensible set of requirements that are drawn from requests of real people trying to get a job done.

Udi Dahan commented as an example, a rule "only a bank manager can authorize a loan above X" which he said couldn't be expressed with Don's idea. It could, indeed, with something along these lines (XPath-like):

<assert test="sec:principal-role('BankManager') and po:Loan/@Amount < 1000">
  Only a BankManager can place a loan of more than $1000.
</assert>

Note that XPath extensibility allows for more domain-specific extensions to be active, which can even check against databases, etc. For example, something like this:

<assert test="crm:customer-id(po:CustomerId)" />

Poor writing style, like bad manners, makes someone appear less intelligent than they are. Writing style, like manners, can be learned in many ways. Reading and writing a lot is the first step. Having people critique your writing is probably the next best thing. There are many basic writing mistakes that people make, which can easily be avoided by being aware of them.

I have never been a great writer and I am self-concious about my writing style. If you are serious about your blogging, I think that time spent polishing your writing style is well worth the investment.

My favorite reference is the Chicago Manual of Style.

Some web pages:

• George Orwell : Politics and the English Language
• Ten Mistakes Writers Don't See (But Can Easily Fix When They Do)
• The Economist Magazine's Style Guide
• rebecca blood's ten tips for a better weblog

Open Source Is "Economically Dangerous"

Dr. Stefan Kooths, with the Department of Economics, the University of Muenster, Germany, argues that open source software is economically dangerous and governments shouldn't use it. On January 15 Kooth lectured on it, hosted by Microsoft Research in Cambridge, UK.

You can see the presentation, as PDF or Powerpoint

I need to make a retraction. It's just come to my attention that the runtime guys are reserving the right to leak stuff if you never call EndInvoke. In the course of trying to pin down who was saying what on this topic, I ran across this statement in the .net sdk docs for the 1.1 framework: "CAUTION Always call EndInvoke after your asynchronous call completes." As far as I can tell, this is the first time they've come right out and said this. And it's contrary to what guys like Box and Grimes have published in books and articles on this topic [2,3]. So if you want fire-and-forget semantics, you'll have to roll it yourself. An example of one possible approach appears below my sig as note [4]. Apparantly this is still being discussed internally, so there's a chance they might retract the cautionary note they've introduced in the 1.1 docs; but that's probably unlikely at this point. -Mike DevelopMentor http://staff.develop.com/woodring [1] ms-help://MS.NETFrameworkSDKv1.1/cpguidenf/html/cpovrasynchronousprogram mingoverview.htm [2] "Essential .NET", 1st Ed., by Don Box, page 194. [3] ms-help://MS.MSDNQTR.2003JAN.1033/dnmag01/html/ASync0108.htm [4]

' AsyncHelper
'
' This class provides a FireAndForget method that facilitates
' calling an arbitrary method asynchronously w/o worrying about
' or waiting for the return value.
'
' The usage model is along these lines (example assumes
' the existence of  Sub SomeMethod(string, double).
'
''Then you create a delegate with the same signature
' Delegate Sub SomeDelegate(ByVal string1 As String, ByVal integer1 as Integer)
'
''Then pass the address of the background method and its arguments
' Dim d As SomeDelegate = AddressOf SomeMethod
' AsyncHelper.FireAndForget(d, New Object() {string1, integer1})

'
' Note - there's an extra (IMO) level of indirection in the
' following code that I don't think should be necessary.  The
' goal is to call Delegate.DynamicInvoke using BeginInvoke.
' Using BeginInvoke gets us asynchrony, using DynamicInvoke
' makes this generically reusable for any delegate.  However,
' when I call DynamicInvoke directly I get an undetailed
' execution engine fatal error.  When I use BeginInvoke to
' call a shim method that just turns around and calls
' DynamicInvoke, things work.  Strange (and consistent on
' the 1.0 and 1.1 runtimes).
'
Class AsyncHelper
    Delegate Sub DynamicInvokeShimProc(ByVal d As [Delegate], ByVal args As Object())
    '
    Private Shared dynamicInvokeShim As DynamicInvokeShimProc = New DynamicInvokeShimProc(AddressOf DynamInvokeShim)
    Private Shared dynamicInvokeDone As AsyncCallback = New AsyncCallback(AddressOf DynamInvokeDone)

    Public Shared Sub FireAndForget(ByVal d As [Delegate], ByVal args As Object())
        dynamicInvokeShim.BeginInvoke(d, args, dynamicInvokeDone, Nothing)
    End Sub

    Private Shared Sub DynamInvokeShim(ByVal d As [Delegate], ByVal args As Object())
        d.DynamicInvoke(args)
    End Sub

    Private Shared Sub DynamInvokeDone(ByVal ar As IAsyncResult)
        dynamicInvokeShim.EndInvoke(ar)
    End Sub

End Class

The good news is that finally, we've got a Web services spec that tackles the hard problem, interfaces. Yes, WS-Eventing is an application protocol (do we have to bind SOAP to it too?)

The bad news is that it continues the track record of abusing other application protocols (if indeed it's objective is to be used with them, which I can only assume is the case); the more that goes in the SOAP envelope, the less suitable it is for use with them, as it just duplicates what they already provide. Once again we see WS-Addressing as the culprit; wsa:Action and wsa:To exist to replace their counterparts in any underlying application protocol. For example, for HTTP, the counterparts of wsa:Action and wsa:To are the request method and request URI, respectively.

A point of frustration for me is that the semantics of subscription itself are largely uniform. What I mean is, wouldn't it be great if all Web services supported "subscribe"? So why not use HTTP like I've done, which is built for uniform semantics? Using a SOAP envelope with MONITOR and for the resultant notifications would be really sweet.

WHAT THE BLOGOSPHERE WANTS MORE OF

Blog readers want to see more:

1. original research, surveys etc.
2. original, well-crafted fiction
3. great finds: resources, blogs, essays, artistic works
4. news not found anywhere else
5. category killers: aggregators that capture the best of many blogs/feeds, so they need not be read individually
6. clever, concise political opinion (most readers prefer these consistent with their own views)
7. benchmarks, quantitative analysis
8. personal stories, experiences, lessons learned
9. first-hand accounts
10. live reports from events
11. insight: leading-edge thinking & novel perspectives
12. short educational pieces
13. relevant “aha” graphics
14. great photos
15. useful tools and checklists
16. précis, summaries, reviews and other time-savers
17. fun stuff: quizzes, self-evaluations, other interactive content

Blog writers want to see more:

1. constructive criticism, reaction, feedback
2. ‘thank you’ comments, andwhy readers liked their post
3. requests for future posts on specific subjects
4. foundation articles: posts that writers can build on, on their own blogs
5. reading lists/aggregations of material on specific, leading-edge subjects that writers can use as resource material
6. wonderful examples of writing of a particular genre, that they can learn from
7. comments that engender lively discussion
8. guidance on how to write in the strange world of weblogs