Journal Notes

 

I love it when a plan comes together. Matt Terenzio: "Why we wouldn't use XMPP as the basis for a decentralized microblogging platform?" XMPP is getting on the scale radar - at last. Dave Winer has picked up on the idea, despite rejecting it last year. Erick Onnen: "Matt Tucker gives a solid overview of XMPP in the integration space with a new post that is getting a lot of press coverage and shot to the top of Digg. I feel like XMPP's potential as an integration tool is finally starting to get the attention it deserves." According to Tucker, Salesforce are also  looking to get out of application polling: " The latest version of Salesforce will send notifications back to your own webservice to avoid polling." [although sf.com's biggest problem seems to be its sheer unusability.]

So perhaps this is what the future of notifications might look like, under the hood:

<iq type='set'
    from='http-service.example.org'
    to='pubsub.example.org'
    id='publish1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='an-atom-node'>
      <item id='70b2a83be71dfca04df91133d953fb22b41b4267'>
          <entry xmlns='http://www.w3.org/2005/Atom'>
            <title>I'm back!</title>
            <id>http://example.org/id/2972afa408f49a7ef9012566297bf3a6<id>
            <link>http://example.org/users/shout/2972afa408f49a7ef9012566297bf3a6</link>
            <updated>2008-01-26T18:30:00Z</updated>
            <summary>gone to the shops</summary>
             <georss:where xmlns:georss="http://www.georss.org/georss">
                 <gml:Point>
                    <gml:pos>45.94 -74.377</gml:pos>
                 </gml:Point>
              </georss:where>
          </entry>
        </item>
    </publish>
  </pubsub>
</iq>

 

To be honest "polling doesn't scale" while ostensibly true, is the least interesting reason to be excited about xmpp-carrying-atom-events-carrying-notifications-carrying-locations (see The boy who cried RSS and The Syndication Sky is failling in!). Atom and XMPP can go anywhere - it's about reach, and simplicity, two criteria for innovative apps - this stuff will go over phones, web, desktops, tv, planes, trains and automobiles. and it's easy to manipulate. Despite it's XML warts, XMPP is a great protocol and great protocols are hard work. If your company is investing in IMS, let me know, so I can short it. 

With a big enough network, I can move the world. So it wasn't the Russians - the Estonia takedown was traced to a disgruntled student, unhappy about the removal of a bronze statue of a soldier. Here's Estonian Defense Minister Jaak Aaviksoo explaining last year why the statue had to go, and later explaining how the DOS was being dealt with. Who knew? Here's a Nato guy last year: "I won't point fingers. But these were not things done by a few individuals." -  file under "inconceivable!". The kid got got fined and will probably have 50 job offers inside a week, and/or be the protaganist in a future Charlie Stross novel. Meanwhile in a another case of technology empowerment of the individual a Societe Generale trader did a Leeson and wiped out 3.6 billions dollars of not-real money (it's not like he burned it in an act of carbo-terrorism). And his friends are leaving him on Facebook. Still, a week off from hearing about Storm or Nugache botnets is a good week.

It's "just" markup. "Using a simple meta declaration, we can specify the rendering engine we would like IE8 to use." There's been a lot of discussion about the X-UA-Compatible header which allows the server to signal to a UA which engine to render on. Ian Hickson: "If Web authors actually use this feature, and if IE doesn’t keep losing market share, then eventually this will cause serious problems for IE’s competitors"  My favorite take is from James Bennett, who hooks the switch into coporate rejection of Vista because it's breaking intranet apps:

"But now the IE team has got the backwards-compatibilty religion, and they’ve got it bad. It’s only natural to ask why, and the answer — I think — isn’t too far off from the official explanation.

There’s only one space left in the market where IdE can still claim that bloated 95%+ market share: corporate intranets. But lately the corporate customers have been a bit twitchy; Windows Vista has been such a disaster, with large customers flat-out refusing to upgrade and some even demanding the option to “downgrade” back to Windows XP on new machines, that Microsoft has extended the sales and support periods for XP, which will now be supported all the way out to 2014 — fully thirteen years after initial release.

And it stands to reason, if Microsoft is bending over backwards to keep its bread-and-butter corporate customers happy, that the IE team would suddenly get backwards-compatibility fever. Except they’re in an absolutely awful situation:

  • In order to keep IE relevant in the general Web-browsing niche, they desperately need to clean up and revamp several aspects of the browser engine, but
  • If they do, they’re almost certain to break a bunch of crufty intranet apps and send the corporate customers even further into apoplexy.

"

It's a great read. If James is right, then MSFT are in a tough spot and I don't envy them (plus desktop apps seem to be on the way out, slowly). Who'd have thought crappy intranet apps encouraged by naive IT versioning policies  ("we only deploy on IE 5.5, because that's all we can afford to test and support!") would cripple Windows adoption? Nobody much wants to think about the cost of doing business with markup and technically it's arcane stuff - most people that use or buy or depend on web apps have no idea how fundamentally bizarre things can be with HTML and XML - Mark Pilgrim has two articles, "XML on the Web Has Failed utterly, miserably, completely"  and "The myth of RSS compatibility", which nicely captures the surreality.  The Lesson? Threefold:

  1. Backwards compatibility decisions tend to be irreversible, and those are the most expensive decisions to get wrong.
  2. Avoid tight compatibility statements unless you understand the tradeoff between eliminating support/quality costs now and stopping your future ability to develop. Models that work for software libraries aren't always applicable to data formats.
  3. "1.0" and "finished" is broken thinking for webapps and services - don't let them sit there and rot, get an in-place upgrade process going

 

 

Tags:

1 Comment


    If we're talking about old intranet apps, then there's clearly a better (for Microsoft and the web) solution than X-UA-Compatible. Two steps:

    1. In standards mode, IE8 should disable conditional comments, fix the remaining CSS hacks used to target IE, and identify as something else in User-Agent. In standards mode, then, IE8 will work a lot like Firefox, Opera, and Safari, and not worry about getting targeted by outdated hacks.

    2. Ship IE8+ with the IE7 rendering engine, and add zoning of "backwards compatible rendering", so that corporate IT can choose sites to render with the IE7 engine. Quirks mode pages always get thrown to IE7's quirks mode. The "backwards compatibility" mode is always and forever the IE7 engine, which will decide between IE7 standards/quirks mode. So even when we're looking at IE12, there's just the latest and greatest standards mode and IE7's two modes for outdated pages. For IE8+ standards mode, developers must write forwards compatible code.

    Actually, I think this is ultimately better than X-UA-Compatible regardless of whether we're talking about corporate intranets or the web at large. The short-term pain of having users mode-switch could possibly be mitigated by either maintaining lists of sites that need "backwards compatible" mode or through some heuristics that automate the switch, and will be considerably better for Microsoft and their users in the long-term than needing to maintain every IE rendering engine from IE7-onwards.