1) Proven scalability.  Compare the ~3 m simultaneous users online at AIM and ICQ with the ~1.5 m Napster and Morpheus (at their peaks).

2) The ability to connect to specific individuals on an IM system vs. the fractional network approach on the current P2P systems.

3) Authorization and buddy lists.  IM has it.  P2P systems offer the ability to ban only.

4) QoS (Quality of Service) is much higher on IM than the current P2P systems. [John Robb's Radio Weblog]
10:17:17 PM    comment   

Sputnik's been flushed into the open: turn a PC into an authenticated gateway, become part of the mesh, share your network, use it for a fee (free for now): Doc Searls blasted me a note about these guys. I haven't had time to absorb the shock of their tiny beep orbiting our known Wi-Fi world. Sputnik software turns a PC into an access point and uses firewall, quality of service, and other components to protect the local network and give priority to local users (and other Sputnik roamers, from what I can tell). This is viral software: if you establish a Sputnik node, you get free access to the rest of the network. More as it develops.

10:16:42 PM    comment   

Aspect oriented programming

 MSDN Magazine showed up at my door while I was away in the UK, and I finally got round to reading it today. First stop: Simon's article on Aspect-Oriented Programming. Nice article, Si. It's recommended reading for people working on legacy (i.e. COM) and undocumented (.NET Remoting Context Attributes) technologies. [Peter Drayton's Radio Weblog]

Extremely well-written piece. I'd recommend it even more broadly. From the moment I saw the declarative approach of MTS and then COM+, whereby transactions, object pooling, and security become externally-managed attributes of components, I knew this was a great idea. What I didn't know, until now, is where it came from. Simon and his coauthors pointed me to the seminal paper on aspect-oriented programming, and connected the dots for me between that paper and COM+ in both pre- and post-.NET environments.

Here's a little of the flavor of that original Xerox Parc paper:

In general, whenever two properties being programmed must compose differently and yet be coordinated, we say that they cross-cut each other. Because GP [generalized-procedure, including procedural, object, and functional] languages provide only one composition mechanism, the programmer must do the co-composition manually, leading to complexity and tangling in the code.

These terms -- "cross-cutting," "tangling" -- are wonderfully expressive.

4:51:56 PM    comment