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

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

On Thu, Apr 10, 2008 at 10:47:02AM -0600, Hal Eden wrote:
> hi,
>
> with je77 having graduated and moving on to a career path, future  
> directions for swiki development are not clear.

<snip>

Hal,

The best analogy I can think of is the Squeak virtual machine itself.
Development is handled by four principle maintainers with occasional
contributions from a few others. The VM consists of Smalltalk code
(in the "VMMaker" package) along with external support code (C code,
makefiles, icons, etc).

The Smalltalk part of the VM is managed in Montecello (but is not yet
on SqueakSource :-/ ). All of the rest in managed in a Subversion
repository at www.squeakvm.org. You could adopt a similar scheme for
Swiki, in which you maintain the Smalltalk package on SqueakSource, and
the external support files in a traditional version control repository
such as Subversion or CVS.

The Squeak VM development relies on people working separately in different
parts of the world, supporting a wide range of computer platforms, and
keeping track of the version compatibility between the Smalltalk part
(VMMaker) and the support files (in Subversion). It's not perfect, but
if it works for the VM, it should be possible to make it work for Swiki.

One suggestion, personal opinion and others might not agree: If you can
find a way to keep the Swiki support files in Smalltalk such that they
can also be maintained in Montecello, I think the overall environment
would be simpler in terms of version coordination and distribution. I
don't know if that is feasible in the case of Swiki, but it's worth
considering.

You might also want to browse the archive of the vm-dev mailing list
http://lists.squeakfoundation.org/pipermail/vm-dev/ to get a feel for
what goes on there.

Dave

On Apr 12, 2008, at 8:39 AM, David T. Lewis wrote:
> On Thu, Apr 10, 2008 at 10:47:02AM -0600, Hal Eden wrote:
>> hi,
>>
>> with je77 having graduated and moving on to a career path, future
>> directions for swiki development are not clear.

<snip, snip>

are there any subversion tools for squeak to ease that coordination?  
(haven't found any yet...)
my impression is that while the VM maker is used to generate the code,  
for the rest of the activity, external tools are used. this is  
somewhat different for the swiki, since most of the manipulation of  
the "swiki source" takes place in the swiki browser.

still might work, though.

> One suggestion, personal opinion and others might not agree: If you  
> can
> find a way to keep the Swiki support files in Smalltalk such that they
> can also be maintained in Montecello, I think the overall environment
> would be simpler in terms of version coordination and distribution. I
> don't know if that is feasible in the case of Swiki, but it's worth
> considering.

yeah, that's the direction i was thinking. i was trying to get some  
sense of whether that was seen as a reasonable approach by those who  
knew a bit more about monticello than i do.

i was looking at some of the MC2 stuff, and the fact that the unit of  
versioning has changed and the use of the idea of slices seem like  
they are steps in the right direction. the parts that seems to be the  
most difficult are the templates and the resources such as icons.
>
> You might also want to browse the archive of the vm-dev mailing list
> http://lists.squeakfoundation.org/pipermail/vm-dev/ to get a feel for
> what goes on there.

thanks, dave, i'll do that.
and thanks for the feedback.

>
>
> Dave
>
>

>
> i was looking at some of the MC2 stuff, and the fact that the unit of
> versioning has changed and the use of the idea of slices seem like
> they are steps in the right direction. the parts that seems to be the
> most difficult are the templates and the resources such as icons.
>
PackageInfo has a method for listing external files.
Monticello Packages are simply zip files.

So it is possible to have MC add the listed files to the mcz.

Keith

On 14-Apr-08, at 7:48 AM, Hal Eden wrote:
>
> i was looking at some of the MC2 stuff, and the fact that the unit  
> of versioning has changed and the use of the idea of slices seem  
> like they are steps in the right direction. the parts that seems to  
> be the most difficult are the templates and the resources such as  
> icons.

Yes. In MC2 the versioning model is better separated from the domain  
model that will be versioned. That is, it's less tied to Smalltalk,  
and can more easily be retargeted at something like a wiki. At the  
moment it's not completely domain-agnostic, but I'll be working on  
that in the next few weeks. I plan to carve Smalltalk support into a  
separate package and make it possible to mix and match domains,  
according to what you need for a specific project.

I haven't been following this thread in detail, but let me know if  
you're interested in exploring the possibilities, and I'll catch up.

Colin