I have to try Nebraska some time, though it sounds like it has all the
disadvantages of sitting together (one machine, sometimes hard to follow
things as they are being done) and of being apart (cant talk, can't tell
if partner is looking). The JabbingBrowser would be less highly coupled
- more like exchanging code by email, only with short turn around,
online chat, and structured data creating endless potential for tool
support.

Daniel

Brian Brown <brian at teuton.org> wrote:
> Quoting Daniel Vainsencher <danielv at netvision.net.il>:
> 
> > I have an idea for something nice, but I'm not sure how exactly it
> > should work. Please let me know what you think.
> > 
> > First, the scenario -
> > I want to program a new feature for SMLoader that requires changes to
> > SM. I email Goran, and he decides it's worthwhile, but we're not sure
> > about the API. The ideal thing would be to start pair programming the
> > changes together. How do we do it?
> > 
> > Well, we each fire up our JabbingBrowser clients. I tell my browser than
> > my definition of the SM categories should be compared to Gorans
> > (pointing out his Jabber presence). A window opens up showing the diff
> > between what each of us have. Because through jabber, he's been notified
> > I care about his change, every time he accepts a method, I get a notice,
> > and my diff updates.
> > 
> A couple of us have been talking about this for a couple of months, but not 
> written anything :)
> 
> > As we're chatting, and I give him feedback on his changes in real time,
> > I decide to start fleshing out my feature, so I can test the API, and
> > see if something's missing. I tell my JabbingBrowser to stop showing the
> > diff, and instead slave my code to his. Now, every accept on his side
> > automatically happens on mine too (with a note to the Jabber client, so
> > I know what changes). Now I can quickly respond to his new code with my
> > own code relying on it.
> > 
> > This, of course, can be extended in many ways, to handle multiple users,
> > asynch changes (what happens when I log off then return and he's been
> > coding), integration with SUnit (set it to run tests when code updates
> > arrive) and more features. But does this seem to work well with the
> > Jabber model? for example, how do we distinguish the code updates from
> > the chat itself? if so, anyone care to hack up a demo implementation?
> > 
> 
> This should work well in the jabber model... put the code updates in their own 
> namespace as part of the message... so their is the standard message payload 
> and also a <xmlns="squeak:code:update"></xmlns> payload in the message as well.
> 
> As far as logging off or on... Jabber stores any messages sent to you until you 
> come online again; as long as your jabber id was being sent messages by his 
> JabbingBrowser, then when you connnected again, you would get them all.
> 
> I still haven't had time to look at Michael's code in any depth to find out 
> what all he has implemented and what still needs to be done, but I would be 
> interested in participating in this...
> 
> (but for the short term, you could use Nebraska :) It works for doing some pair 
> things, it just doesn't have two focus abstrations, so wherever the insertion 
> point lies is where both parties type. Just like in VNC, except you *do* have 
> two mouse pointers)
> 
> Brian
> 
> 
> > Daniel
> > 
> > 
> 
> 
> --