November 22, 2004

Rapid Solutions Explosion

First there were a few. Today, several more, in the Groove Rapid Solutions Exchange (aka
Snapshot Appshots to Get You Cooking) (aka Zen and the Art of Office Automation).

November 19, 2004

A picture

I suppose this is the "echo chamber" they talk about.


Smart Clients

My bloglines-fed Groove workspace has a category-name, by the way: "smart client". Here's Microsoft's Scott Garvey talking about what that means...

(interviewer)"What started the conversation out was, people are asking, you know, where are all the smart clients?...
(Garvey)I think what we're finding is, smart clients is really the phase two client that gets in front of these web services. So the natural client, when you first produce some web services, the first client you think of is "oh, let me put it in a portal". ...what we're finding is we're replacing our portals and providing smart clients.
...Yes, you want to read that. But then if it's "hey, let's act on that information... you'd better put that beyond a browser and into a smart client.

What Scott doesn't mention (after all, "evangelism" means "talk, no trousers") is that building a smart-client is all about leverage: how much function you get for your line of code.

Microsoft has some "patterns and guidance", a "deployment guide"... Eventually they'll end up building tools for this into Visual Studio, into Office (IWBridge, and so on) - but from listening to Scott, building smart clients sounds like hard work. It's not!

The Groove / Forms / Web Services / IntegrationApp stack I'm using gives me "Bloglines offline shared with a group with notifiers and presence and all that, with secure automatic offline synchronization and multipoint update, etc etc": for a few hundred lines of code. Specifically, "bloglines.cs" (my webservices wrapper for bloglines access) is 475 lines of verbose C#. And "class1.cs" (the integration app) is 350 lines. It took four hours to build, including the rich forms UI.

November 18, 2004

Bloglines API

I spent a little while recently experimenting with the BlogLines Sync API. It's good - and very easy to use; in only a few hours, I built a little application to pull news from Bloglines into Groove Forms.

Using the Bloglines aggregator as a news source is interesting: sure, this is a centralized service; but it's a nice way to avoid the complexities of handling RSS/RDF/Atom "in the wild". It also turns out to be really efficient. More technical details below the fold.

So, we built a shared space and invited a bunch of people in there; news updates are pulled in every half-hour (from my extensive blogroll). With Groove's notifiers, unread-marks, presence, and extensibility, this feels like probably the best newsreading environment I've found yet... Hopefully we'll find a way to get some variant of this code into your hands soon.


seems like many people's favourite newsreader nowadays. The usual UI is a web browser, so there's no client-side hit (other than an optional notifier - the Firefox notifier is neat). I have to admit ditching the (otherwise very good) SharpReader because of its startup overhead. Bloglines is great for work/home mix, although it's no use for travel-reading.

There's a privately-held company behind this somewhere, with no visible means of support. How quaint is that? Anyway, Mark and co are obviously pouring in resources somehow - the site hasn't often been slow.

Some virtues of centralization

There are some really interesting linkabilities-of-scale which Bloglines is beginning to exploit: Technorati-style, identifying the links between weblogs; and, more important, beginning to function as a real social hub by showing who's reading what. It's strangely comforting to know that nobody else subscribes to del.icio.us/tag/odd, and that my own blog's subscriber-count is way up in the long-tail thirties.

For a consumer of the bloglines web services APIs there are some really tangible benefits:

  • Clean data! All feeds have been pre-digested into an RSS-like structure, and they're all the same format. This is so good.
  • A single socket to call. I can scan a thousand weblogs with a single thread. I only need to call HTTP GET on two URLs.
  • Unread marks (or rather, built-in high-water-marks). When I call "listsubs" to retrive a list of all my subscriptions, each item includes an unread-count. Then, iff that number is more than zero, I can call to retrieve the unread items (and simultaneously mark them as read).

My next wishlist item will be to handle enclosures (for those podcasting feeds). And, luckily, the"getitems" API does return enclosure links. But... the flipside of clean data is that the API might not change as quickly as usage, or be as rich as RSS or Atom extensions can make it.

Bottom line: for a developer who wants to quickly build RSS-feed information into an application, this is a treat.

November 16, 2004


David Scott Marley has a weblog I'd recommend to y'all. He writes well, and care-fully.

Hundreds of thousands of people are going through hell there, and the vast majority on both sides are probably people who I'd like just fine if I sat down with them and shot the breeze for a half hour sometime over a cup of coffee or a beer. This is all so terribly wrong.

It was so damned unnecessary that our soldiers be put in this position at all. Every step of the way here was unnecessary for us to take; nothing was calling to us along this path but the greed and xenophobia and egotism and desire for control and craving for power that poisoned Saddam Hussein's heart and poisons the hearts of our own leaders as well. And hundreds of thousands of lives have been needlessly damaged and destroyed for it.

Talking about people named Scott (not DSM, another one): if you want to call me a coward for being shocked at the scale of civilian casualties, then just stop reading. I don't write this for you.