Craig Latta wrote:
>  > > I'm just putting in a word for an approach which I think is more
>  > > worthwhile, despite taking longer to realize (because the work is
>  > > less incremental).
>  >
>  > Less incremental is a pain in the rear.
> 
>     Sometimes it's worthwhile. 
Sure.

> I find it can be less a pain in the rear 
> than being forced down a dead-end, constantly led forward by the 
> short-term ease of "the simplest thing which could possibly work". :)
> 
>     Surely this is just the old "blue/pink planes" dialectic.
Doesn't sound like it to me. I alway understood blue/pink as being about 
your direction. Incremental implementation is about having a safe way 
there. Of course what paths are safe depends on who you intend to take 
along for the ride.

>  > What makes it less incremental?
> 
>     In the particular technical design I advocate, what makes it less 
> incremental is producing a very small object memory to use as a starting 
> point, reorganizing existing modules to work with it, and actually 
> making the switch. I grant this is less interesting if one isn't 
> interested in very small systems, and in knowing how every single part 
> fits together, but I do. :)  One reason I am is that it'd be useful to 
> have small object memories which are responsible for housing a small, 
> focused portion of behavior (e.g., live mirroring of changes made to a 
> normal development system).
Well, I do find the destination of that story pretty interesting, and it 
might be easy to get from there to good code sharing. But it doesn't 
sound like the shortest route to code sharing...

>  > ...why couldn't/shouldn't it be done as incrementally as what I
>  > mentioned above (an alternative substrate for MC versioning)?
> 
>     I think Monticello's model of package composition and behavior 
> transfer is too coarse. 
Ok.

> As I understand it, applying changes via 
> Monticello is built around a one-way bulk transfer of information from 
> producer to consumer, using a declarative model. 
That's how it generally happens at the moment.

> I think computing what 
> ought to be transferred should take into account what the consuming 
> system already has; there should be a live conversation between the 
> systems. 
This is pretty much what I propose in the previous mail. I think it 
would fit just fine with most of MC, and enable some very nice 
improvements in the sharing experiment. For example images could notify 
one another of new versions when they are created, which is certainly 
less elegant to do via the current medium of files and websites. So in 
this sense, making some MC based clients that communicate by remote 
message sends might be the shortest way to better code sharing.

>     Instead of using that declarative model, and transferring that data, 
> I think it makes more sense to get the system elements themselves 
> communicating directly, with the help of annotation (e.g., compiled 
> method version IDs, class IDs). 
I don't know, sounds too low level to me. So when I decide to version my 
contacts objects, I'll need to teach them who to talk to and how to do 
three way merges with my PDA image? Sounds better to just teach them to 
flatten to declaration objects that MC can deal with...

 > I think that would be simpler, smaller,
 > result in less network traffic, and lead to fewer undecideable
 > situations during behavior transfer.
These claims make me curious. When would you have less undecidable 
situations? have a simple but precise example?

On another level, I'm assuming you're not going to duplicate all this 
version handling logic many times. How do you define the units of 
versioning without a declarative model? is there a url I can read that 
tells this story?

>     I guess a shorter way of saying this is, if you can do it with files 
> (non-interactive data transfer) you're doing the wrong thing. :)
Maybe :-) but maybe that's not the wrongest way to be wrong...

>  > Well, a lot of nice assumptions go out the window at physical machine
>  > boundaries.
> 
>     But not the ability to send messages and get answers, right?
Guess that depends on your ISP... :-)

Daniel