Bijan Parsia bparsia@email.unc.edu wrote:

One thing I really like about SqueakMap is that it brings things to me. No need to go out and find the right web page or archive: SM brings it home to my image. Yay!

Even better, it makes me want to pound on things, extend them, fix them, play with them, even write documentation. All to the good.

For example, I loaded up MinneStore and it seemed to work ok, in some places, and not as ok in some others. Some things were just a bit disobvious, though with a bit of explaining, they would be clear. Some things needed a UnitTest or 4. Etc.

I started doing a few of these things but then realized that I had No Good Place To Put Them. I could, of course, do the old go out and find the right web page, contact someone, send [BUG]s and [FIX]s and set up a Swiki page...ugh. No! I'm feeling lazy. I want *SqueakMap* to do this for me. SqueakMap is *magic*...it can fix *anything*.

Yes, this is of course on the MEGA todolist for SM.

But my first impluse...to create Yet Another Package, seemed wrong. I

Yes, that would be wrong. :-)

don't want SM cluttered up with twelve dozen tiny packages, often with just 5 lines of code. I like the clean glowing lines of SM goodness.

But I also want everything in SqueakMap.

Basically, if each SMCard was itself also a SMCategory (or sufficiently like one) with a certain set of subCategories (e.g., Tests, FIXs, BUGs, Enchancments, Documenation, Request/Comments/Tips) then there'd be a natural organization of these bits and pieces and a clear association of them with the "parent" package.

Hmmm.

Seems to me to fit in with the use of SqueakMap for the Harvesting process...except that every package maintatiner gets to be their own Harvester. (E.g., there could be ways to indicate that a particular fix has been incorporated.)

I have been thinking along the same lines but with a different solution. I want each package to have an "incoming" and an "update stream" for it. The update stream is probably optional because some developers would probably instead work using frequent releases, but the incoming could perhaps be selected (by the maintainer when registering the package) from these:

1. Simple email. When you select "Send change to package..." and then select one of the installed packages in your image it would then look at that SMCard and notice that, hey, that maintainer simply wants it in the mail. Send it off. 2. An ftp incoming area. Same procedure but the change is instead uploaded to an ftp area for the maintainer to pick it up from.

So, this would enable us to very easily just send improvements to a "package" without having to know how the ChangeSorter does this - we just select the package and shoot!

The next thing I would like to have is a general "annotation" mechanism on SM, so that people can add small "notes" to a package like bugreports, cheerful appreciation and advice etc.

But anyway, before these things will happen I have some MAJOR things to do first:

1. Package releases. 2. Making the web UI irrelevant by adding API in SMSqueakMap for registering/updating packages. 3. A few other important boring things. Like publishing the current master web UI and add a mirroring mechanism (very easy).

There are a couple of ways of implementing this, though it seems fairly straightforward, but I wanted to see what people thought first.

I am have a few objections here :-)

1. Having the cards "be" categories clearly sounds "cool" but muddles the water a bit, doesn't it? 2. When someone loads the map you don't necessarily want to load info about every little fix/enh to every little package out there. In this respect I think it adds "too much" to SM.

The annotations I talked about is also a tad close to number 2 above, but if the maintainer can clean it as he/she sees fit then it wouldn't grow in absurdum. I see it as a little "bulleting board" associated with the package that the maintainer has full power over - anyone can put a note up there but the maintainer decides to let it stay, remove it etc.

And finally - the SM implementation is being considered "as we speak" to form a little base around a new "Harvesting tool" in which similar thoughts are hashed out right now. Read more on that on the SqF Swiki under "Guides". I need to write down my thoughts there as well - Doug has written his.

Cheers, Bijan Parsia.

Cheers, Göran