[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
|