On Jan 25, 2010, at 12:36 PM, Juan Vuletich wrote:

> Hi Folks,
>
> (reposted, in the hope of not being ignored)
>
> Package developers want their work to run on various Squeak versions  
> and variants, without needing rewrite. Same for app developers.
>
> Base image builders want to be free of the need to provide backwards  
> compatibility.
>
> This is what I suggest: A package assumes it can use a set of apis  
> of the Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment.  
> Those assumptions should be made explicit, in the form of tests. So,  
> for example, for collections, some package developer might require  
> the "Common Collection API tests" to pass. Then, if his package  
> fails to run, let's say in Cuis, he would run the tests for the apis  
> he needs. If some test fails, he could say "Cuis developers, you're  
> not supporting api XXX", end expect them to fix the issue. But if no  
> test fails, he needs to either modify his code so it doesn't use not- 
> standarized apis, or he could negotiate with (all) base image  
> developers the addition of a new api or use case to the test suite  
> and the base images.
>
> Building these suites is quite some work, mostly to be done by  
> package developers. But it can easily point out responsibilities and  
> duties. It frees package developers of needing to have a deep  
> knowledge of various base images. And it frees base image developers  
> from needing to know details about an unbounded set of external  
> packages. Besides, it puts popular packages that everybody wants to  
> support on equal footing with less-known packages. It also lets base  
> image developers say "we support Common APIs xxx, yyy, zzz, etc.".
>
> All what I say about base images could also apply to packages that  
> offer services to other packages: There could also be test suites to  
> specify their services, and allow users to switch versions of the  
> packages they use knowing what to expect.
>
> What do you think?
>

The overall concept makes sense to me re: getting to a common set of  
APIs.  It would be nice to have it in the form of formal protocols  
eventually but tests would provide a simpler starting point.  This  
wouldn't just be helpful to image and package maintainers, but also to  
developers in general as API documentation is often lacking and an  
effort like this would (hopefully) encourage developers to better  
document what they produce.

> Cheers,
> Juan Vuletich
>
>

Thanks,
Phil