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
> 
> 


--