I love this blogging thing, word gets around, at the speed of deferredness. :) I also love the way other Smalltalkers have similar ideas and take steps towards achieving it. [Spotted in Avi Bryant>http://www.cincomsmalltalk.com/userblogs/avi/blogView?showComments=true&entry=3241520114]

Here's my revised IRC pairing idea.

It's too hard to go package level granular. So instead I'll invent a new package meta-field called 'channel' which'll be an IRC URL, such as http://irc.parcplace.net:6667/public_code

Any body using the pair programming system can move through the RB as normal, but they will have a red light up in the corner of the package saying "Hey, I'm not sharing" - if they click that they can do a number of states, sort of like ICQ states: Disconnect, Syncing, Sharing, Listening, Patching

• Disconnected: You quit the channel, and disconnect from the server if you're not connected to any other channels on that server.
• Syncing: You listen to other peoples code and load it in to your image. You also post out any changes you make.
• Sharing: You post out changes you make, store any other peoples changes you hear about, but do not apply them in your image (this is most likely the most common state you'd want to be in).
• Listening: You store any changes other people make, but do not apply them to the image.
• Patching: You nominate people you will instantly accept code from, but don't publish out your own code. With this state you could be sitting on an official Cincom channel receiving live patches?

Whether or not I actually implement all this stuff is another matter. Right, that handles moving code around via IRC for the public, what about security and what about just pointing people to code?

By nominating channels for your packages, you can have that channel set up with a password on your local machine. This password is never published anywhere. If you're the first to join a channel, you set up the password on the channel. If you are not the first to join the channel, you try to use the password to enter the channel - standard IRC security.

Pointing people to bits of code! - We still have normal chat rooms. So why not invent a way for TypeLess to share a 'code url' in the chat room. It'll appear as a hyperlink to be clicked on - but it will also move in to a 'navigation history' area some where so you can back track what bits of code people are talking about. Then we add a right click on bundle/package/class/method to 'post' the url to one of the channels you're currently chatting in.

The key to all of this is the UI. Without a good UI you're sunk. Icons in the RB will help a lot. Icons to show you you are connected or not, icons to show you what state you're in, icons against methods to show you that people have offered up changes to that code. Simple UI tools to look at the changes and throw them away. And being minimal. We want to integrate with what's already there, not invent whole new paradigms. That means storing other peoples code in to a change set of its own and pushing off browsing the code in to the changes tool.

There is only one problem that springs to mind: Synchronisation can only work from the point you are both listening! The best form of synchronisation is to load from a store. I do not intend to make the Syncing state 'retro' synchronise late comers. that's just too hard.

Another problem is VW's source messaging. It's really bad at telling you things have changed. So here's the hit list: The only changes that will be broadcasted are: class shape changes, class deletes, protocol changes, method changes, method deletes. Package properties.

Right!, this is a HUGE job. So I won't be doing any of it any time soon. I may fiddle with the 'code url's at some point, but don't hold your breath for any of this. I'm almost in the mood to make TypeLess less of an IRC client and more of a code sharing tool. I'd fork TypeLess in that case and call it.. eh.. CodeLess? :)

Because I want the UI to be minimalistic. Much of IRC is over kill for these jobs. There'd be no admining the code channels. Any control of that would have to come from the ircops. Sorry! I'm just not interesting in solving ALL the problems :) Having a system open for abuse is nearly impossible to solve for a publicly shared system.

One other thought: tieing an RB to a particular person/channel navigations? - tieing your RB to continually tell a person/channel where you are? - not that crazy an idea..