Peter Merholz has an interview with Valdis Krebs, whose work on social network analysis and knowledge managementI recently discovered. Anything which "...allows us to look at and map what are normally invisible dynamics inside a community" is a good thing, although it's painfully clear that these are babysteps.

Weblogs and social network analysis tools are highly complementary, and I think they're at similar stages of development. It's beginning to be possible to follow "who-reads-whom" and "who-comments-on-what" links, and use these to map the network of connections. But simply mapping the connectivity tells us little about the meaning of the connection (in the weblog world, a link is a link, and it's generally a positive comment), and even less about its effectiveness.

I'm not sure effectiveness is the right word, there. Something like "empowerability" is what I'm looking for. If you need to take action, what support do you need in doing that, and how do you marshal your resources to make it happen? Can social-network analysis tools help with that?
This is partly about knowledge management -- do I have the right context? what do I need in order to make a decision? -- but it's also a very political question: do I have buyin? what do I need in order to have this actually happen, if I can't do it by myself?

Take the Palladium story:

These weren't trivial guys... [one] quickly brought in a couple of very senior research architect level guys and a key guy from the [OS] team. They worked on this in their spare time... they really pushed this thing. And other forces in the universe have come around to where this has clearly emerged as an idea whose time has come. Because these guys are really good, and they know how to make things happen at Microsoft, they finally succeeded in having this established as a product unit.

TrackBack is quite complex, but the MT bookmarklet makes it fairly transparent to use. Even if this is only the first revision, the idea's out, and it adds a useful extra dimension to weblogs.

Just when I have 2.1x installed (over 1.x), I gotta upgrade.

The TrackBack system looks particularly interesting. It's like referer-based backlinks, but doesn't wait for referers; when you post a link to a TrackBack-enabled page, their backlinks update right away. Very smart.

Following the lead of Disenchanted and Mark Pilgrim: the backlinks in the left (below the calendar: another nice and easy-to-use Movable Type feature) are implemented with a perl script from Waxy.org.

I'd seen some of the first news coverage of Microsoft's Palladium. Now Here's an interview with the product manager, Mario Juarez.

We regard it as pretty significantly evolutionary, because for the architecture we've got here - a new breed of hardware, new capabilities in the operating system, and over time new applications and services - we think it will provide some very significant things in the way of security, personal privacy, and system integrity.

I practised first, on Dylan's site. Template needs some work, but the content moved well enough. The UI takes some adjusting to.

RSS is automatic now (in the same places as before). I still need to install SOAP::Lite to make Google and XML-RPC work.

Reconsidering MT. The cabezal.com site is mostly an experiment in "how dumb can I treat this server" (but actually it's feature-packed: preinstalled with perl, PHP, MySQL and stuff). Using an active server I could more easily do comments, backlinks, and other cool stuff. I could even make it a reverse proxy into a Groove blog-space, I guess :-)
A quick question for Moveable Type users: how do I move my blogger archives into MT? (Don't worry, I got it).

The question of how to connect Groove to the "outside world" has several answers. I'm constantly amazed by Tim's ability to cook up code overnight: he's now running a webservice inside a Groove tool, with bidirectional Web access. This is really powerful - a "view-level" parallel of the "model-level" SOAP stuff we're calling Edge Services.

Luckily Tim has a Web-accessible (dynamic DNS at "kicks-ass.net") machine. My main Groove device usually sits behind a firewall. To solve that problem, the Edge Services piece will have "always visible" access points relaying to and from your client in much the same way Groove's relays already work. For a Web system like Tim's, it might be cool to have a reverse-proxy (cacheing?) do the same thing. Or even to bake Grooveness into dynamic DNS (so, for example, a "grooveTelespace://" canonical URL could be served by any online member of the space, or by any device running my account).

vowe follows up my troll about innovation and software dependencies.

Installing the Groove client is not an option for everyone, especially not in tightly controlled environments where the user works as a Windows 2000 restricted user. So how can I collaborate with him? Only through web based technologies... that do not require a client install.

Fundamentally, there's a new collaboration dynamic which is enabled by Groove: secure shared spaces, for immediate and persistent interaction, with no "central services" requirements, cross-Internet, from your own PC. Have Groove, can travel (and get work done whilst travelling). You can quickly see the value of shared spaces - "getting on the same page" - when comparing this with the typical CYA use of email.

(btw: I don't have a comment feature here only because I was too lazy to properly dig into Movable Type. But I quite like "blog tennis" anyway).

Volker Weber writes:

In case you have not taken the Groove tour, I would suggest that you do it now. You will be amazed by what you can do with the product. Less my what it tells you but how it is done.

You will also see the main obstacle. If you don't have Groove installed you can't take the tour. That is true for the whole product. If your coworkers don't have Groove, you cannot use it to collaborate. Big difference to other web-based collaboration tools like eRoom or Quickplace. How did Bob Balaban put it so nicely? A telphone does not make a lot of sense if nobody else has one.

Diversion (or: a challenge to Tim: what are you doing this weekend?!). Cassini: "...is, in a nutshell, an HTTP server written in C#. It's fully HTTP/1.1 compliant... it's all open-sourced, free to the public, and weighs in at 10 files, 7 core classes, and less than 50K of total source code". The core webserver is only a handful of lines. Plugging this into a Groove tool should be very straightforward. Decouple it from the filesystem (because filesystems, generally, stink); and have it serve streams directly from your shared space. Roll-your-own "edge services".

Honestly, this is the "easy bit" (because it avoids the issues of cross-firewall access, multiple-devices-for-one-identity, intermittent-connections). But I've not seen it done yet.

Groove Tour design, part three. Latency and stuff (or at least, a lead-in to those things).

First off, it helps to understand how Groove's shared-space synchronisation works (at least to some "comfort level"... I'm usually happy just to say that Groove keeps shared spaces in synch, and you don't need to go any deeper than that). When you're building Groove tools, and especially when integrating with other systems, the synch model is quite important. I don't claim to understand the dynamics in detail - I only work with it from the outside, so things may be way off base. But here we go.

In your shared space, transactions happen on the database (database = the space and its contents) when things happen in the space. Users initiate transactions, usually by waving a mouse around or typing. The transactions change the state of the (XML) database underneath. These transactions are also put into message queues directed at the other endpoints of the shared space (the other participants' devices). Eventually, they're quite likely to arrive. Actually, the Groove "dynamics" service pretty much guarantees that the transactions will arrive and be processed, in the same order, on every endpoint of a shared space (and if that fails, your endpoint is "out of synch", and you and every other endpoint in the space is made aware of that synchronization failure, and you can get reinvited to the space if you want).
That guarantee takes some magic. In particular, it means that there's a transaction log associated with each database, and very often (because the network flakes out, or because things simply arrive at different speeds, or because PC clocks are never synchronised, or Joe did some work on the aeroplane and just plugged back in, whatever) you'll find a "missing transaction from the past" arrives. Because Groove has already made a best-effort to keep current state (so that the space doesn't simply freeze if something atomic is missing), the database will roll back a little, insert the newly-arrived transaction, and roll forward again. Bingo. You're up to speed.
(Which then gets into all sorts of transaction-integrity stuff. Don't worry. If you have transaction dependencies - x must happen for y to occur - then there are ways to express that. In the tour, I'm really only interested in very simple sequential, independent, transactions).

To sum that up (it's late... keep this short...) you have an interesting choice when looking at a Groove shared-space. Are you interested in the "current state"? Great; it's always being synchronised with any other participants in the space. Sharing state is incredibly easy: for example you use a propertylist
  PropertyList.SetProperty( sPropName, pValue, nFlags )
where the default flags are GroovePropertyFlag_Serialize + GroovePropertyFlag_Disseminate); or use a RecordSetEngine (which has rather more structure, and indexes, and stuff); or use a DocumentShareEngine (which does binary documents very easily).

But the Tour is concerned instead with tracking changes in state - sequenced events. That's actually just as easy - the events in the Tour are set on a propertylist using the code below. Each event is a "delta", and is disseminated to the other endpoints, and processed when it arrives. But when you receive these events, time can flow both forward and backward. Now that starts to get fun. And more serious discussion will have to wait....!

	var pEl = CreateNewElement("urn:training.groove.net:TourEvent");

	pEl.SetAttribute( "Name", sEvent );

	pEl.SetAttribute( "Param", sParam );

	// some other parameter stuff elided for brevity

	pEl.SetAttribute( TOUR_INSTANCE_ID, sInstanceID );

	pProps.SetProperty( 

		sEventType, 	// we only have types of "bot event" or "client event"...

		pEl, 

		( bDisseminate ? GroovePropertyFlag_Disseminate : 0 ) + GroovePropertyFlag_Serialize );

I just love the way Web browsing can lead you to undiscovered depths. I never was much of an academic, but this seems relevant to the tour. (That via Patrick Logan, via Jon and Sam). Next I'd better talk about how (and how little) the workstation and bot synchronize, about latency, transactions, and planned interaction.

More Tour.
As you can see in the earlier snippets, the tour script has stages and actions. There's also a "default stage" named with an asterisk, where you can put default event handlers (such as the client example: wherever you are in the tour, this will trigger when the event matches). If you specify parameters on the <t:Action> element, that action will only triggers when the parameters match; a regular-expression parser makes parameter matching quite flexible.

Events happen from all sorts of things. At the workstation, client-type events are raised: navigation, space members arriving, chat, a timer (which you can stop and restart), windows opening and closing, by instant messages arriving or being sent, roles changing, and a few others. The bot watches all the tools in the space and triggers events appropriately (documents being added, deleted, modified; and so on). The script can also trigger custom events. Then each user (workstation and bot) shares their events across the network, so effectively the event model is seamlessly location-independent. There's a latency in the network, of course; that's sometimes quite important (as we'll see later on).

In the raw application, stage names are not coordinated between actors. The tour implements a "stage follower", though, since coding gets a lot easier if you can track stages automatically by default; the code looks like this:

	<t:Action Trigger="PropertyChanged" Param1="CurrentStageUser">

		if( tour.DoesStageExist( Param2 ) )

			tour.GoTo( Param2 );

	</t:Action>

<t:Stage Name="*">

	<t:Action Trigger="WindowOpen" Param1="Add Recipients">

		tour.PushBookmark();

		tour.GoTo( "HandleRecipientsDialog" );

	</t:Action>

</t:Stage>


<t:Stage Name="HandleRecipientsDialog">

	<t:Action Trigger="Timer" Param1="2">

		ui.Bubble( "This is how you find Groove contacts." );

	</t:Action>

	<t:Action Trigger="WindowClose" Param1="Add Recipients">

		tour.GoTo( tour.PopBookmark() );

	</t:Action>

</t:Stage>

blogToaster (via Ben) - weblog notification by IM. Neat.

Time to start writing about the Groove Tour. This may be interesting to people who want to build with the Groove EIS; also more generally to provoke thoughts about distributed, coordinated applications. I'll start here; if there's more you want to know about what or why or how, then please ask.

[Aside: this is unstructured train-of-thought doc. I already have some internal-use developer doc, and this is different. If there's a good way to convert train-of-thought into structured documentation without breaking its readability whilst in progress, I'd be interested to find it. Documentation has two time-and-space domains: "in progress" (linear time, nonlinear content) and "wrapped" (linear content, nonlinear time). Meanwhile I'll just dive in and say things as they occur to me.]

The aim of the tour framework is to make a little, generic, "conversation engine" inside Groove. The first application of this is a self-paced guided tour of Groove. You begin with some slideware, introducing Groove Workspace. Then an instant message arrives from a co-worker (a bot). You reply to the message, and wind up inviting this "person" into your shared space. Then you add some tools, and hold (primitive) conversations using those tools (and chat).

To implement this, there's a very loosely-coupled pair of state machines: one at the client, and one at the bot. Each state machine runs a script, through which interesting events are processed. Most of the events are transparent across the network connection, so that the bot sees what's happening to the client (at some level), and the client sees events which originated at the bot, too. There's some optimisation to keep the chatter down: "timer" events aren't disseminated, nor are windowing events at the client, nor are instant-message events (although that's mostly to protect privacy, rather than to reduce chatter). There's a hard-wired restriction right now that the tour involves just two participants: one user, and one bot; there's not good reason for that, and it's not a big deal to remove later.

The other aim of the tour framework is that the state-machine's scripts be editable by a non-developer. That's a hard aim to meet, since I don't really know what a non-developer is. In this application it means: you don't need to know much about programming. You still need to grok the hard bit, though: coordinating actions at two locations, using separate (and loosely-coupled) scripts, to achieve some didactic purpose. To see how that works, here's an example of the script code. (This is XML and JavaScript. Maybe a better format would have been better. I don't know.)

In the client script:

<t:Stage Name="*">

    <t:Action Trigger="Chat" Param1="/^stop/i" Param2="user">

        tour.Trigger("GoEnd");

    </t:Action>

    <t:Action Trigger="GoEnd">

        if( ui.MessageBoxYesNo( "Do you really want to finish the tour now?" )=="YES" )

            tour.GoTo( "TourComplete" );

    </t:Action>

</t:Stage>

In the bot script:

<t:Stage Name="TourComplete">

	<t:Action Trigger="Initialize">

		tour.StartTimer();

	</t:Action>

	<t:Action Trigger="Timer" Param1="3">

		var sMsg = "Your Groove Tour is complete now...\nCongratulations.";

		tour.SendIM2( tour.GetUserURL(), sMsg, "c:\\thankyou.wav" );

		tour.DeleteSpace();

		tour.StopTimer();

	</t:Action>

</t:Stage>

What is Twisted? (via McCusker)

Twisted was originally designed to support multi-player games; a simulated "real world" environment. Experience with game systems of that type is enlightening as to the nature of computing on the whole.

Wired: The Madness of King George

Gilder draws a parallel to the tech collapse of the mid-1980s, which compelled some to proclaim the death of the PC era. "We've seen this kind of thing happen over and over again through the history of enterprise," he says. "It's enormously disappointing for the visionaries, yet it's not the visionaries but the people who inherit the infrastructure they've built who typically prosper from it."

Catching up with weblogs again, there's a big void. I do hope Dave gets well soon.

Rules of Thumb: "What is economical to put on disk today will be economical to put in RAM in about 10 years". And, "[Web] cacheing is very attractive: cache a page if it will be referenced within the next 5 years".

Ugh. Flying eastwards overnight is such a bad experience - no sleep, no night, and caffeine doesn't fix it. If the travel experience were in any way acceptable I wouldn't mind so much, but this time was really bad: two-hour checkin queues, overcrowding at the gate, sardine-packed economy class seating, seats stuck in the middle of a row, obnoxious nerd in front who sets his seat right back for the whole journey, obnoxious people behind who leave their overhead light on the whole time; and the wrong meal. Awful. So today I'm not feeling particularly effective.

Does "The Private Press" rock? I think so.

Shaping up for a busy day. I want to write lots about the structure and operation of the Groove Tour, but maybe that'll wait. The inlaws (well, not really inlaws until later today...) arrived last night to babysit for our US trip. Meanwhile I gotta visit the dentist, take our library books back, write some more documentation, clean up my Flash-embedder code, nail down a couple of client-side bugs, go uptown for some formalities, fire off some emails, then get on a plane, arrive, and drive from Logan to Newburyport.

In a welcome return to "punching holes in stuff" as a storage mechanism, IBM's Millipede (that's an InfoWorld link, so you have to ignore those stupid underlined words) potentially goes to terabit-per-square-inch. Quite an improvement over tape and card, Millipede "uses thousands of nanosharp tips to punch indentations that represent individual bits into a thin plastic film".

One long and productive weekend. Despite appearances, I spent most of the nights debugging the Tour, and only a part of the daytime hacking bootstrappers. Some good advice from John, though: "next weekend - turn of your PC. Leave it off for the whole weekend. Have a life". Luckily my next weekend is booked already: North Shore househunting.

Jon Udell reports back from Groovespace (the RU/Groove space, which has been a focus for so much interesting activity over the past few days). That man can write good. He also has nice things to say about the newsclient tool, which get to the heart of Groove itself:

Suddenly the experience became qualitatively different. This news aggregator was a group resource. I immediately saw it as a way to work more effectively with (for example) my new colleagues at InfoWorld. I know of no other way to focus the attention of a group on a stream of news which is guaranteed to be identically and persistently available to everyone, and at the same time to be able to support collaboration around that stream -- i.e., discussions about which items to pursue.

Some more concept hacking, under the moniker of skunkworks. This is a way to punt some of my work-in-progress (things being built or discussed by my group at Groove) over the wall. It's not cooked; mostly it's not even flame-grilled. If you want to know more about the way this stuff works, get in touch (the Web forms are just really simple PHP).

Testing. Click here to go into the RU/Groove space. (This won't work for you...)

Ernest Adams in Gamasutra (registration required), "Indie Game Jam": what can you build, with four days and a hundred thousand sprites? The results are interesting...

In a Groove space (with Jon, Jeroen, Tim, Matt and others) we're having some really good conversations about integration of Radio Userland and Groove. Matt bootstrapped this with a thoughtful piece about their relationship, and Jon has been asking lots of good questions. Here's one of my posts there.

Radio is neat for several reasons (and every day, it seems, Dave invents more). I've spent a while trying to abstract the real nuggets in there, and there are loads. But I think a key one is this: the Radio web is a peer-to-peer information network, where the routers are humans. Radio's subscription, aggregation and publishing functions are subservient to the routing function.

That sounds kinda like "gnutella search by carrier pigeon" - the latency of transmission is measured in hours, if not days.

But in practice it's really powerful, because the routers are "tuned" (in really human ways): we pick up and forward things which resonate. Not by creating (say) RDF-encoded tables of "who knows what" and "who knows who" (link) but by cross-linking the knowledge network in ad-hoc ways.

I've started producing local RSS feeds from this weblog, replacing the indirect feeds from blogify and voidstar. This will help me track referers, and will help newsreaders' performance too. Update your subscriptions (please).

What is stumbleupon? (via blaven)

What is Goo.NET? (Or... why?!)
(use double/dotnet/system_windows_forms_messagebox)
(system-windows-forms-messagebox-show-string "Hello World!")

BoingBoing has a good writeup of Howard Rheingold's talk at Reboot (latest in the list of Conferences I'd Love To Be At).