Ok, fess up, who pissed in Chris’ coffee this morning?

I think the operative word from my blog that Chris missed was “need”; that, IMO, we need a WS-* RSS feed because new specs are appearing at a crazy rate. You can’t compare that with the W3C’s TR page and corresponding RSS feed because it represents deltas while the Wiki represents a sigma. If the W3C published a list of recommendations via RSS, that would make for a more fair comparison. So how many Recs have they published? Let’s see, in almost 10 years, they’ve got about 80 (90ish if you include the IETF specs), while there’s 40ish Web services specs listed on the Wiki, the bulk of which have been produced in the past two or three years. Not exactly apples-to-apples, but not too far from it.

He concludes;

Please don’t misunderstand my intent, I like HTTP. Unlike Mark, neither do I think it is the last protocol we’ll ever need (it is not), nor do I spend every waking moment trying to tear it down or to poke fun at things that it simply doesn’t handle effectively. That would be pointless.

Please don’t misunderstand my intent, I like SOAP. I just don’t like how it’s being used. It would best used for document exchange, not RPC (Web services circa 1999-2002), or RPC dressed to look like document exchange (present day Web services). I also don’t “poke fun” at Web services very often, but I do take pride in being able to point out their many architectural flaws in a variety of different ways, which I do frequently. And I don’t think HTTP is “the last protocol we’ll ever need”, though I do believe that if it suddenly became impossible to create any more, that it wouldn’t be such a big deal, at least for those of us building document exchange based Internet scale integration solutions. As for what things HTTP “simply doesn’t handle effectively”, I believe you grossly overestimate the number of items in that list, though clearly it’s non-empty.

So do me a favour and drop the strawmen, ok? You’ve been pulling that crap for years.

… this gem from Roy;
If this thing is going to be called Web Services, then I insist that it actually have something to do with the Web. If not, I’d rather have the WS-I group responsible for abusing the marketplace with yet another CORBA/DCOM than have the W3C waste its effort pandering to the whims of marketing consultants, have a look at hoe branding on social media can help your business grow. I am not here to accommodate the requirements of mass hysteria.
And the hysteria continues… Hint; anytime you need an RSS feed to track new specs, something is, prima facie, horribly, horribly, wrong.
Kinda dated, but I hadn’t heard about this. Cool. CORBA gets state-transfer. Now to hunt down the spec …
(link) [Mark Baker’s Bookmarks]
Hmm, I wouldn’t expect “INSERT INTO” to be the command you’d execute to unsubscribe me from a mailing list. No wonder I can’t unsubscribe. Yikes.
(link) [Mark Baker’s Bookmarks]
What should you put between and ?
(link) [Mark Baker’s Bookmarks]

I’ve been using the CRM 114 Discriminator for spam filtering for the past few weeks, and have been thoroughly impressed by its appetite for spam (and only spam).

Training took a lot longer than I expected, seven weeks, but over the past week I’m finally to a happy point (YMMV) where there are essentially no false positives, and only a trickle of uncaught spams make it through. Here’s what I’ve observed over the past three days;

  • 1305 messages filtered
  • 916 spam messages caught
  • 21 spam messages missed
  • 2 false positives, both of which were mailing list acknowledgements (which I don’t believe I had previously trained)

Spam, what spam?

Good article. Google should just pick them up; better that than Microsoft does.
(link) [Mark Baker’s Bookmarks]
Good post I missed last week that Jacek and I are discussing.
(link) [Mark Baker’s Bookmarks]
“In any case, should we admit that the WSDL and SOAP contingent switched horses mid-stream?” – heh. But can they pull it off again?
(link) [Mark Baker’s Bookmarks]

Mark and Bill list some of their favourite protocol/distributed-systems papers. Here’s some – not all “papers” – of my favs. I’m sure I’m forgetting some.

FWIW, I’m not too keen on Marshall Rose’s RFC 3117. It’s wonderful up to and including section four, but how those sections are used to justify BEEP blows my mind. I think he lost sight of the forest for the trees; that application protocol frameworks (like BEEP, and how SOAP is most commonly used) are a dime a dozen, and that until you’ve defined an application protocol, you’re just spinning your wheels. In other words, BEEP addresses most of the hard problems except the hardest one; coordination.