<html><div style='background-color:'><DIV>
<P>Diego makes an interesting point about there being multiple groups within the overall Squeak community, each pulling the language in a different direction.&nbsp;</P>
<P>A possible solution to this is to organize 'families of&nbsp;functionality' as separate projects in the same way that the Apache Jakarta work supports developers building Web-centric Java applications by providing a central source for (among other things): the tomcat web server,&nbsp;the struts web application framework, a mail server, xml processing, test utilities, etc.&nbsp; These things have become semi-official parts of the java development world without being part of Sun's official Java (except for the XML stuff, which is repackaged).&nbsp;&nbsp; The project provides not just a set of tools but also&nbsp;confidence -&nbsp;that the projects are active, the tools have a certain quality and that, to some degree at least, they work together.&nbsp; This 'branding' effect is very important.&nbsp;</P>
<P>The benefits of this are several:&nbsp; First, the basic image can remain small without preventing access to useful tools.&nbsp; Second, the time-consuming process of blessing image changes can be avoided.&nbsp; Third, those 'families' that meet real user needs will thrive while others can fill smaller niches, or fade away entirely - without having to remove them from the image later.&nbsp; Finally, if&nbsp; the tools prove valuable to mainstream developers, they can always be rolled into to the image later.</P>
<P>There's enough existing software&nbsp;to form the basis of a&nbsp;'traditional' development family - Comanche, Seaside, some of the database tools, SOAPOpera, XML-RPC, etc.&nbsp;Whether or not their developers would want to work this way is&nbsp;the real question.&nbsp;&nbsp; </P>
<P>---------------------------------------------------------------------</P>
<P>Hi,<BR><BR>I think we're really near to find *the* source of all these discussion we<BR>have periodically since SqC leaves Disney.<BR><BR>What we want with Squeak? Clearly there are 2 groups:<BR><BR>&nbsp; - The "Media-Squeakers" (in Andreas's words)<BR>&nbsp; - The "Traditional-Squeaker" (in my words)<BR><BR>I'll try to explain creating radicalized descriptions of these groups:<BR><BR>The Media-Squeakers believes in Squeak as the most promising incarnation of<BR>the Dynabook concept. These guys want TTF in the Image, Sound, Midi, PDF<BR>support, SVG readers/writers, Improved Look&amp;Feel, Video support, etc and<BR>they are able to accept a big core image.<BR><BR>The Traditional-Squeakers are more interested in "normal" development with<BR>Squeak and they are interested in SOAP, Relational DB Access, CORBA, CVS<BR>support, cgi-type web servers, native-widgets, etc.&nbsp; These guys want a<BR>really small core image with nothing more than stdio support.<BR><BR>If we don't agree with the goals difficulty we'll agree on methods.<BR><BR>We have to decide what we want with Squeak and accept that, probably, the<BR>goals of these groups are not the same.&nbsp; Personally I think we have not<BR>enough resources to try to get all the goals of both groups.<BR><BR>In the SqC age the Media-Group was in charge and Squeak has excellent<BR>multimedia capabilities and absolute no support for "traditional"<BR>development.&nbsp;&nbsp; In the Guides-Age these goals, imho, are not so clear.<BR><BR>Cheers,<BR><BR>Diego<BR><BR><BR></P></DIV></div><br clear=all><hr>Add photos to your messages with  <a href="http://g.msn.com/8HMJENUS/2749">MSN 8. </a> Get 2 months FREE*.</html>