[plt-scheme] PlaneT, plts and distributing software.

Following up with a thought about this.

> Jacob Matthews wrote:
> 
>> If you write (require 
>> (planet ... ("usr" "pkg" X Y)) where X and Y are numbers, you're NOT 
>> saying "get version X.Y of the library," you're saying "Get a version 
>> of the library that's totally compatible with version X.Y" -- in other 
>> words, any package that implements version X.Y's entire interface and 
>> behaves in a compatible way. (PLaneT's rule for what's compatible with 
>> what dictates the version numbers, which is why I don't let people 
>> choose version numbers for themselves.) 

I do agree that this mapping between interface+expected behavior, and 
specific implementation versions, could be useful to support.  The issue 
I raised is just a question of who gets to control the mapping.

If you accept the requirement that I've raised, which is that there are 
(often) times when it's desirable to be able to specify the specific 
version of the implementation of a collection that an application 
depends on, then it becomes necessary for the PLaneT server to support 
requests for specific implementation versions (and to reliably honor 
those requests, i.e. no baiting & switching allowed!)

The mapping Jacob described can still be supported, though, as a layer 
above this.  If a collection is requested by its "interface version" 
(for want of a better term), then the appropriate implementation version 
would be looked up in the interface/implementation map.  (By 
"interface", I really mean the combination of interface+compatible 
behavior which Jacob described.)

Given a design like this, the exact same mapping system could be 
supported on the client, rather than (or as well as) on the server. 
That would allow developers to control the implementations that are 
retrieved in response to requests for an interface, and would allow them 
to guarantee what happens when they distribute a program without its 
dependencies.

Anton