Hi Keith,

keith wrote:

> Hi Juan,
>
> I have been looking for a viable kernel on which to build my future 
> production images, and a friendly community in which to participate.
>
> We had tabled the idea of forming a "guild" of nice people and 
> squeak/pharo package developers for those of us who develop packages 
> that we would like to be available to all oss smalltalkers. The 
> problem being that squeak/pharo cores are wildly shifting sands, 
> intent on imposing the ideas of their creators upon us, and they 
> aren't really kernels, nor are they progressing in that direction.
>
> However with Cuis being more minimal, the architecture has the 
> potential to be better layered, into kernel, system and application 
> layers. Discussions in irc, seemed to suggest that Cuis might be a 
> viable option.

Good!

> I have lots of questions and ideas.
>
> My first question is, do you have a plan?

Not really. But I'll keep developing Cuis along the ideas described in 
http://www.jvuletich.org/Cuis/Index.html .

> And where would be the forum for discussing plans.

So far, it is here.

> Are you on irc?

No.

> Do you have a process for contributions to the Cuis kernel?

There have been few contributions to Cuis so far. The current process 
is: you send them to me, I review them, and if I like them, I load them. 
Before spending a significant amount of time doing something you'll like 
to see included, please ask me. This will reduce the risk of frustration 
for not seeing your stuff included.

> In irc #squeak we had an impromptu discussion about making MC1.6 
> loadable, and providing tools like Sake/Packages and Installer for 
> Cuis. I think that the ethos of Cuis being simple enough to be 
> understandable fits quite well. For example, Installer was originally 
> designed, as a means to an end, to be 1 class, but the "Installer 
> replacement" new kid on the block "Gopher" is 33, and Sake/Packages is 
> 4ish classes but Metacello is 40 classes. By the time Pharo has MC, 
> MC2, Gopher and metacello loaded you are looking at 400 classes in the 
> image just for doing a #fileIn!
>
> In contrast Sake/Packages can potentially use a visitor to walk the 
> dependency graph, in order to generate scripts. So "Bob the Builder" 
> can potentially generate and apply a build script to an absolute 
> minimal cuis image using #fileIn:

Personally I'm not really interested in automatic building of images. 
But I understand others might be, and I welcome your initiative.

> I propose a way forward, to establish a number of initiatives, 
> mini-projects, with the aim of contributing to the "kernel" of Cuis, 
> and dividing up "System" to be a set of loadable modules to make 
> "core/system" layer.

So far I'm quite happy with the base image being monolithic. I'd like 
loadable packages to be used for optional stuff. What would be the 
benefit of splitting the base system that way? How long would it take to 
have a usable system again?

> I propose prefixing cuis discussions on squeak-dev with [Cuis] so we 
> can filter out our discussions from squeak noise. Is there a cuis-dev 
> list?

There is not a Cuis specific mail list. A [Cuis] prefix is a good idea.

>
> So as an example, HTTPSocket/Network is conspicuous by its absence. 
> Shall we estabish a project to work on this, or is it in hand?

For a project I'm working in, I have SWHttp, Yaxo, a very reduced 
version of OSProcess, UnixDomainClientSockets and UriFramework. I'll 
make them available soon. UriFramework is especially nice, handling 
downloads, local cache, up to date verification, etc.

>
> regards
>
> Keith
>

Cheers,
Juan Vuletich