[squeak-dev] Cross fork compatibility of packages: A proposal

Julian Fitzell jfitzell at gmail.com
Tue Jan 26 18:40:21 UTC 2010


Heh, I don't know if all developers will find it appropriate for their
needs yet; it's obviously providing primarily the stuff that Seaside
needs but we're certainly hopeful it will become helpful to others
over time. I'm going through an exercise with all the platforms at the
moment to extend the defined protocol a bit. Getting agreement on
stuff is a slow process... :)

I've said a couple of times I need to write a blog post about Grease's
goals... I'll try to do that this week.

Currently Squeak is pretty much using the Grease implementation
defined for Pharo, though that may become less practical over time.
You could try loading Grease-Core, Grease-Pharo-Core, and
Grease-Tests-Core into Cuis and see how much passes. :)

Julian

On Tue, Jan 26, 2010 at 6:44 AM, Juan Vuletich <juan at jvuletich.org> wrote:
> Great! So, it is not a new idea. Let me suggest all the package developers
> to adopt Grease and help develop it! I'll be really happy to give support
> for Grease in Cuis.
>
> Cheers,
> Juan Vuletich
>
> Julian Fitzell wrote:
>>
>> This is kind of what Seaside's Grease platform is starting to provide,
>> so obviously I think it's a good approach. Grease documents "standard"
>> APIs that we expect on all platforms via unit tests. Each platform is
>> then required to ensure the tests pass, either by fixing their base
>> image, or by adding extensions to their Grease package.
>>
>> If Seaside doesn't work and all the Grease tests pass, either we need
>> to change Seaside, or add a test to Grease. We've now begun using
>> Grease as the basis for Pier, Magritte, and MC2, so the hope is that
>> it might become generally useful to other projects that want to write
>> code that runs across platforms (we're not just talking Squeak forks
>> here though; this includes VW, VASt, GemStone, Gnu, etc). That's a
>> lofty goal, though, and we're taking a pragmatic, step by step
>> approach.
>>
>> Julian
>>
>> On Sun, Jan 24, 2010 at 10:07 PM, Juan Vuletich <juan at jvuletich.org>
>> wrote:
>>
>>>
>>> Hi Folks,
>>>
>>> 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?
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>>>
>>>
>
>
>



More information about the Squeak-dev mailing list