October 22, 2003


AudioMulch 0.9b14, mirror here:

This version adds support for all common real-time sample rates up to 192kHz (previously hardwired to 44.1k). Included are a number of usability enhancements such as new patcher right-click menu items for Replacing, Inserting and Bypassing contraptions without having to connect and disconnect patch-cords; and the ability to define a "default" document used as the basis for all newly created documents. There is a new FrequencyShifter contraption, and Mute and Solo buttons have been added to the Mixers.
Have fun!

(Update: patch build released, and updater, more details)

SmartDocuments and InfoPath

Peter O'Kelly has two new articles (drafts, PDF): Smarter Documents, and Projecting InfoPath. Coverage in depth; well worth a read.

I've done a little SmartDocuments development, and don't find it easy to share his enthusiasm completely: the developer documentation is difficult to parse, and the experience wasn't a whole lot of fun. I do think the concept is powerful and important, and opens some fascinating possibilities - just a note of caution if you're thinking of diving in with both feet.

The potential of SmartDocuments is quite interesting, really. It appears to be part of a very broad "reclaim the desktop" strategy, where integration traditionally seen as "enterprise-scale" -- workflow, content management, legacy systems context -- becomes part of the Office experience, instead of stovepiped into separate desktop- or browser-based application interfaces. Which is a smart strategy, both in terms of an Office hegemony and enhanced user experience.

October 21, 2003

Home from home

Groove Networks Takes the Microsoft Office System "Out Of the Office". Today is Office2003 launch day, and we have something to say. Especially about SharePoint and InfoPath:

The Groove Mobile Workspace for Windows SharePoint Services uniquely extends the value of InfoPath 2003 by transporting InfoPath forms solutions from the server to the PC, allowing XML forms-based information to be captured anyplace at anytime. With Groove Workspace, mobile InfoPath users can literally bring their XML forms solutions with them wherever they go, and provide third parties with secure access to forms. The combined Groove Workspace, Windows SharePoint Services and InfoPath 2003 solution is optimal for field-level or cross-company business processes that require extensive information gathering, such as sales, sourcing, procurement, customer relationship management, and more.
The Groove/InfoPath integration really is very very cool. (Full disclosure: I built this!). It's still very very cool. Useful, too.

Check it out. You'll need the Groove 2.5i maintenance release, and a Professional license. Then: "create shared space" - "standard toolsets" - "Mobile Workspace for SharePoint", and point it at a SharePoint site which includes an InfoPath form library.

Also notable because we embed a small Groove Web Services client inside InfoPath. This brings pieces of Groove -- member awareness, instant messaging and invitations -- right into the Office application.

October 20, 2003


Game Neverending, meanwhile. Looks fun; MOO-like server, and a very good mixture of Flash and Web user interface: the main environment is Flash, but most things are web-accessible too. There's even the beginnings of a web services interface (this is cute).

And Liz Lawley notes, Disney are just launching a "ToonTown" MMORPG, for kids. For ten bucks a month (!!). See, there is a market for this stuff. There's a business we could decentralize nicely, eh?



Mica is a system for building network-accessible multiuser portable applications. It is a programming language and object environment designed to be accessible by more than one programmer at a time. It includes an implementation of a mostly pure object oriented language. Automatic persistence, reflection, strong encapsulation, multiple dispatch, and run-time security are some of its features.
A post-MOO language design. It would be really interesting to have some of these environmental features on a Groove base, wouldn't it? Language-transparent persistence. Singleton (instance) objects with prototype inheritance. (Distributed XML, too?) Hmmm.

Which reminds me that one of the unusually smart things about LambdaMOO was its security model, in a world where "untrusted code" was everywhere. Individual verbs (methods) execute with the privileges of their author, as I remember. Which is neat (if your world includes wizards to do the dirty work)...

David Fowler

Robin Good interviews David Fowler, Groove's VP Marketing.

October 15, 2003

Alarmed and suspicious

Electronic voting machinations in the Independent:

Alarmed and suspicious, a group of Georgia citizens began to look into last November's election to see whether there was any chance the results might have been deliberately or accidentally manipulated. Their research proved unexpectedly, and disturbingly, fruitful.
"Enough to stand your hair on end".

October 14, 2003


Joel Spolsky says exceptions "are significantly worse than goto's... A better alternative is to have your functions return error values when things go wrong". Ned Batchelder and others disagree.

I'm with Ned (approximately). Con: JavaScript doesn't have "first chance exception" handling, which is a royal pain. Pro: "finally" is a wonderful thing. Mu: If there's an interface demarcation which uses result codes, that's fine. But neither model is really great for asynchronous programming.


Danny O'Brien has a hilarious and serious take on the FooCamp "s00p3r s33krit confab":

In the real world, we have conversations in public, in private, and in secret. All three are quite separate. The public is what we say to a crowd; the private is what we chatter amongst ourselves, when free from the demands of the crowd; and the secret is what we keep from everyone but our confidant. Secrecy implies intrigue, implies you have something to hide. Being private doesn't. You can have a private gathering, but it isn't necessarily a secret. All these conversations have different implications, different tones.

On the net, you have public, or you have secrets. The private intermediate sphere, with its careful buffering. is shattered. E-mails are forwarded verbatim. IRC transcripts, with throwaway comments, are preserved forever. You talk to your friends online, you talk to the world.

This is why, incidentally, why people hate blogs so much... The answer why they won't shut up is - they're not talking to you. They're talking in the private register of blogs, that confidential style between secret-and-public. And you found them via Google. They're having a bad day.

October 11, 2003


Via Patrick Logan: Skip Lists: a probabilistic alternative to balanced trees (PDF):

Skip lists are a simple data structure that can be used in place of balanced trees for most applications. Skip lists algorithms are very easy to implement, extend and modify. Skip lists are about as fast as highly optimized balanced tree algorithms and are substantially faster than casually implemented balanced tree algorithms.
Very nice. The paper is completely self-explanatory, and the cookbook has a little more detail, but if you want to see the illustrations in action, here's an applet to play with.

October 10, 2003

Plain text

Joel Spolsky:

Please remember one extremely important fact. It does not make sense to have a string without knowing what encoding it uses. You can no longer stick your head in the sand and pretend that "plain" text is ASCII.

There Ain't No Such Thing As Plain Text.

If you have a string, in memory, in a file, or in an email message, you have to know what encoding it is in or you cannot interpret it or display it to users correctly.

It hurts every time I have to say that, too. Luckily, I think, everyone I work with understands it now.

October 09, 2003

JavaScript misc: #include and debugger

A couple of pieces of JavaScript trivia.

The debugger; statement doesn't seem to be very widely known. It brings you into the script debugger. (For scripts in IE, you'll need to enable script debugging, by unchecking Tools - Internet Options - Advanced - "disable script debugging"). As to which debugger you get, well, I haven't worked that out yet; I get to choose from a list of the half-dozen installed script debuggers. Strange that Microsoft should produce so many, really.

Eric Lippert explains why the language itself doesn't have #Include. Now here's a trick for web pages to include an arbitrary script at runtime. (Same with commentary, here).

October 06, 2003

Groove and WSS

Laurent Kempé: "That's it !!! Groove is working with the Windows Sharepoint Services. I just had a try after the update of Groove Workspace 2.5i and it WORKS". Indeed. I'll have more to say about this later.

October 04, 2003


Jon Udell takes a look at collaboration in Microsoft's Office 'system':

Here’s a trick question: What is Microsoft’s collaboration server? The answer used to be obvious: Exchange. Now it’s not so clear. Suppose you want to hold a discussion. You can still do that transiently in an e-mail thread, or with more permanence in an Exchange public folder. But Live Communications Server injects a new ingredient into the mix: IM-style presence. If you can see that the participants in the thread are online, you may want to switch to chat mode. Or you could launch a discussion on a SharePoint site that displays presence indicators. Even more intriguing, an Office document can now be a locus of presence-enhanced SharePoint collaboration.
...Users will find no single unifying theme akin to the Groove shared space.
Indeed. Although SharePoint is the closest thing to that. Actually I think there is an underlying theme, just Microsoft didn't realize it yet...

October 03, 2003


Lippert strikes one out of the park: "With" considered harmful. The clearest, most eye-opening exposition of JavaScript's "with". In Eric's comments:

devs who are used to the VB-style "with" -- which is a syntactic sugar -- fall into the trap of believing that JScript "with" is also a syntactic sugar when it emphatically is not! ...it allows devs implement dynamic scoping rules in a lexically scoped language -- but 99.9% of the developers who use "with" are looking for the sugar, not dynamic scoping!


Daniel Hedrick: "I've been using Groove off and on for a year or so, and I'm hooked".

October 02, 2003

Telepresence culture

Matt Webb has a great series of posts exploring presence and the way people interact in virtual environments.

I think we've found that virtual reality isn't necessary for presence, only that the behaviour of something that appears to be "human" is transmitted through the behaviour of the medium.
We're at an interesting stage, where lots of communications technology is becoming "socially invisible" - mobile phones and WiFi-enabled computers are everywhere, taken for granted. There's a two-way movement of models and ideas between the real and virtual environment.

Two people standing in a park, waiting for a call. The phone rings. Guy ('tis his mobile) answers; Gal, although obviously keen to become a part of that virtual place, has to stand and wait for the call to be done. A three-way online chat can happen fluidly and quickly - but real-world telephone "conference setup" is wickedly complicated... why?

Web services

Dave Winer says

...it would be more convincing if Groove were open to competition, or at least open to being built on. When they came out with web services interfaces, finally, after years of waiting, the excitement was dampened because it didn't work with the programming environment I use. Maybe they are open to be extended, but, practically are there any extensions from people who are not working at or closely with Groove?
OK, let's look at that again.

"Open to being built on". Groove has had an in-process development model (ie. build on the product, with code running in the framework's own process) from day one. Starting in 2000, my team at Agora built a set of tools, using our favourite kit: JavaScript, Visual Basic, XML and SVG.

To work with the Groove application from "outside" - a non-Groove.EXE process - use the GWS web services interfaces. I'm mystified by Dave's comment about "it didn't work with the programming environment I use": the wire protocol is SOAP. OK, so your programming environment can't use the "doc-literal" SOAP format natively? Why not fix that? Tim has done it. I've used GWS from Visual Basic, JavaScript, C#, perl and PHP.

SOAP-based access to "local system services" - collaborative services based on your desktop, in our case - really is a huge deal. Of course we're working with Microsoft kit more than anything else - as I hinted earlier, their development environment support for building web services clients really is exceptional - you hardly need to know that you're calling remote services, let alone the mechanics of how the message gets dispatched from A to B. That ease-of-access will be very important in the future, I think.

And, for an example from someone not working "at or closely with" Groove - how about Zhou's screenshot (in OS-X, in Shanghai)?


update: Jeff points out the screenshot isn't OS X, just a nice skin! Confused me, anyway.

October 01, 2003

qotd, 09-17

"Shrub is reluctantly saying one thing and Cheney goes on national television and flat lies through his teeth. If those are his teeth". Ha.

Workspaces and email


Anyone who is doing a critical business process online that involves substantial dialog between individuals should NOT be using email at this point in history, and many no longer are.
If you have work to do with others, online, try workspaces. There are many different types - from Groove if you like client-based mobility, to SharePoint if you like using Websites... you'll only visit eMail as a low-priority background task, much as you do when sorting through your physical mail at home. You'd never do important work through your home mailbox, would you?

Update 10-02: Sean and Scott add:

I've tried probably 300 different ways of organizing my inbox over the years and nothing works all the time for every situation.... What I want is one tool that does what Groove, Sharepoint, and Outlook do for me that works in Offline and Online modes and is one tool. It's really more of an issue of focusing on what the work is that people use the tools for as opposed to the tool itself...


The customer is always right... even when their requirements aren't clear (are they ever?). When the specifications are in flux, one sensible response is to build a framework.

Frameworks, after all, are a negotiation with the future.

The background

I've been working with an external customer recently, on a reasonably small integration component of a Groove deployment. There's an Oracle database, populated nightly from SAP and Siebel systems, which needs to drive some activity in custom tools in Groove spaces; and some of the information being used in Groove should be sent back to the Oracle database, where it'll be directed onward to SAP, Siebel or wherever.

So far, so good. The outline requirements are clear, and reasonably straightforward; I'll use Groove EIS ("bot server") to build a single integration point, 24/7, and the bot will be a member of all the relevant spaces. Since I've worked with EIS before, it was quite straightforward to build out the skeleton of my application: a scheduling strategy, some "space lifetime" management, that sort of stuff.

The actual data transfer (being the raison d'etre of the bot) was a bit more murky, though. To build the bot I'll need: the Oracle table schemas, the Groove tool schemas, and a map of how the data moves from A to B. None - repeat, none - of this information was available.


It quickly became clear that the schemas - and the mechanics of the data transfer - will only be absolutely frozen a few days before this system goes into production. That's not anyone's fault; there are at least four different groups working on the pieces of this, and everyone's working hard.

My bot, sitting pretty on the critical path, needs to be able to accommodate changes quickly. I suspect that there'll be customer-driven changes even after we roll this thing out; and I definitely don't want to be rebuilding and redeploying code for each change.

So, of course, I set to building a framework. My bot reads a configuration file (XML), which specifies exactly how to connect to the database, how to find the tools, and any number of "jobs" which move data from one to the other. There's a mapping table, to take field X into field Y. There's a primitive transformation syntax, to calculate things which aren't a simple field transfer.

So, you can edit the configuration file without even shutting the bot down; changes will take effect immediately. Code become data. But now, the configuration file almost looks like a programming language of its own... state, loops...

Configuration editing

I've used a similar strategy a few times, and it's usually worked pretty well. One downside is that a sufficiently powerful configuration syntax (in XML - so it's verbose and not necessarily too readable) becomes really really difficult for a "non technical user" to maintain.

On the other hand, I couldn't justify the time and expense of writing a full "configuration editor wizard".

Maybe InfoPath would do that job really well, though. It's worth considering for next time. (That link URL says "preview", but I'm sure it's RTM already...!)


One lesson: if you're going to build a framework, decide it early. That way you'll get a good, flexible, road-tested framework. Plan for re-use. And make it easy to use right...