On 27-Nov-08, at 1:28 AM, Andreas Raab wrote:

> But why do you need proxying and protocol compatibility? The only  
> reason I've ever found was to make sure existing tools (browser etc)  
> can work with those proxies. Is this what you're after, e.g., have a  
> browser with a "commit" button which then does all the changes  
> atomically? If not, I'm not sure what you need the proxying /  
> protocol compatibility for.

Well, yeah. My immediate goal was atomic loads for MC2, which was  
already working non-atomically using the existing protocol. It wasn't  
completely trivial to make MC2 use SystemEditor, but it was pretty  
easy. Now that the work has been done, turning atomic loading on or  
off is a one line change. It could be a preference.

But beyond that, the barrier to adoption to these sorts of things is  
always tool support. The browser is actually the least interesting  
tool in this case, since it makes one change at a time, and you  
usually want them applied immediately anyway. It might be useful for  
especially fiddly stuff like hacking on Compiler, but that's pretty  
rare. I was actually more interested in tools that load code in bulk:  
MC1, MC2, file-in, SAR, SqueakMap etc.

The alternative would have been a protocol with methods like  
#classNamed:addInstVar:, written as part of MC2 rather than as an  
independent package. That could still work, if compatibility turns out  
to be more trouble than it's worth.

Colin