user types

Lex Spoon lex at
Sat Mar 5 20:59:46 UTC 2005

Avi points out that a packaging commons needs to support social
mechanisms -- and perhaps even engineer new ones.  This observation has
a lot of ramifications.  It means there is not an obvious Right
Solution.  It means that version 1 may well not work the way it was
expected, and thus that we need to be prepared to watch how the tools
actually get used and adapt to what people want.  Some features,
painfully, might not turn out to be useful at all.  We should be careful
not to get so attached to our theories, that we refuse to recognize what
the users are actually doing.

But we have to start somewhere!  Let me try and sketch some user types
that seem nice to support.  This is by no means a final list, but we
have to have *some* working model.  Please add anyone I left out, or
adjust any types you think are off the mark.

There are several familiar user types:

1. J. Hacker goes to, gets hooked, fools around, and is
excited enough to develop some code that they'd like to share with the
other Squeak users.  It's important to support J. Hacker's, because they
are the main source of all this great code that we'd like to share

2. Fred Exec likes golfing but hates computer innards.  If someone gives
him a CD with SqGolf 3000 on it, then Fred should be able to use it and
to apply updates as Avi described in the kickoff email message.

Let's keep in mind some less familiar types, as well:

3. The Scratch project is a local work group within a research lab, and
they'd like to build something cool in Squeak.  They would like to use
stable packages that have been posted to the 'net, but they do not need
the bleeding edge.  They plan to eventually share their project on the
web, but they would like in the meantime to keep their ugly looking code
to themselves.  Nevertheless, they are multiple people, and they can
greatly benefit from having the repository tools still work for them.

4. Joe Porter might want to port BottomFeeder from VisualWorks to
Squeak.  Our infrastructure should allow redistributing stuff which is
primarily maintained somewhere else.

5. HP Labs has some cool Squeak code that only makes sense for use
within the organization.  It would be nice if HP lab rats can use the
package repository infrastructure to share this code amongst themselves.
 They should be able to do this regardless of which other Squeak
projects they are involved in; e.g., they should be able to collaborate
with the Scratch guys using an image that has HP Lab packages loaded.

Some initial implications on the tools, based on these user types:

There should be some very easy publishing mechanism available, so that
J. Hacker can get their code seen by people who are interested.  There
is a big difference between posting something on a web site, and posting
it to something like SqueakMap.  For mysterious reasons, packages in the
former category seem likely to wither compared to the latter.

There should be a way to have local repositories, so that the Scratch
group can make progress.  One implication of this is that identifiers of
all kinds are going to have conflicts between the local repositories and
the well-known global repositories.

It looks like mixin repositories would be useful, in order to support HP
Lab's internal packages.

Along these lines, it would be ideal if it is possible to manage a
package manually, without reference to a repository.  It should be
possible for one Squeaker to send a newly created package file to the
Squeaker sitting beside them on another computer, without invoking lots
of infrastructure.


More information about the Packages mailing list