On 2006 August 28 10:50, Giovanni Giorgi wrote:
I have little time but I am a Software Architect. So if you (=the community/board directors) like I can draw some guidelines for the SqueakCore project. For instance we can draw together some basic rules for API deprecation, unit testing and so on.
Hi Giovanni,
Thanks for commenting, and sorry for my late reply, I marked this thread as "todo", but then never looked back until now, with discussions about Strongtalk, I remembered I left something on my "todo/reply" that is related.
I do not have much to add, while I continue liking the idea of defining modularity and well-defined interfaces (and possible interchangeability) between VM[Current, Pepsi, Strongtalk]<-->Core[Current, Spoon]<-->Packages, (which themselves would be loadable/unloadable starting with the "lowest level" such that Tweak/Morphic/NativeUI), I am simply not qualified enough to drive such SqueakCore effort, or have enough time to help significantly. Having said that, if someone, or the board, goes this direction, and such modularization effort is established, I will try to participate and help to the best I can (which may amount to well below 1 cent :) )
Milan
Drop me an email :-) My 4 cents (yes I am a bit more rich :)
On 8/26/06, Milan Zimmermann milan.zimmermann@sympatico.ca wrote: [...]
Yes that makes sense. I felt uneasy commenting on this given I am barely a weekend squeaker, but got encouraged by the original question "what would it take for you[squeak-dev list member] to "buy in" to a central governance model for Squeak".
Also, Squeak would continue to evolve the Squeak we know. Discussions about tossing it and starting from the ground up are interesting but off topic. If you want to do that, then you are free, but Squeak's organization should take care of Squeak.
What I had intuitively in mind (by saying it would make sense to encourage alternative cores) would be their existence would show the API to the core is well-defined and hopefully stable. In a way similar to ability to run (a large set of) packages such as KDE on both Linux and FreeBSD shows there must be well-understood API to the cores (perhaps with different adapters but still defined). Apart from that clarification I agree talking about alternatives was off-topic.
Milan