[squeak-dev] extending monticello to support swiki development?

Hal Eden haleden at colorado.edu
Thu Apr 10 16:47:02 UTC 2008


hi,

with je77 having graduated and moving on to a career path, future  
directions for swiki development are not clear.

there has been a little discussion on the pws list about migrating  
this effort to some shared development environment such as sourceforge  
or squeaksource. (mark seems to be supportive of something like this).

i don't believe that sourceforge really supports squeak development  
well, so i tend to lean toward squeaksource, but it is also not a  
perfect match.

for those not familiar with the swiki substrate, there is, on one end,  
the squeak classes and methods that implement the core functionality.  
these "live" in the image and are easily supported with monticello and  
squeaksource. at the next level there are what i would call "swiki  
source"--code in the form of addresses and actions that interact with  
templates and form a large part of the specialization of various wiki  
types. these are not part of the normal squeak code hierarchy but are  
managed by the squeak code. (addresses and actions are basically  
smalltalk code kept in files that are loaded in, wrapped in a block  
and compiled. there is also a swiki browser that is used to interact  
with the swiki address, action, template, and settings definitions.  
there are also a number of support files (e.g., icons, css) that are  
used in various ways. finally, there are the page files, which  
represent the content of the wikis.

as far as i know, the primary mode for development was within a small  
number of people, so the need for distributed development was minimal.  
it seems to me that the ways of sharing code was either
	1) an entire distribution (which usually took the form of an image
		(although there was generally a "source release" as well)
		and a tar of the files (actions, templates, addresses, icons,
		starting pages, etc) needed)
	2) a set of instructions such as "change this file", "create this  
action",
		 etc--basically an individually-tracked mechanism.
i have found this to be less than ideal, even in local development  
within a small group.

although we could continue this mode for distribution of releases, it  
doesn't seem to be a good match for the development process. i find  
that a major part of the development takes place in the set of swiki  
addresses, templates, and actions, so i would think that an approach  
similar to what monticello uses for packages, classes, methods, etc  
would be appropriate. the elements are after all just other forms of  
code elements that might be merged, diffed, replaced, etc.

do any of you monticello "experts" know how difficult something like  
this might be, whether it is in line with or antithetical to the  
monticello/squeak source approach, or have any other insights into the  
problem?

thanks

hal





More information about the Squeak-dev mailing list