SM has passed 500 packages!

hjh-sqlist hjh-sqlist at lexdb.net
Mon Jan 3 15:06:40 UTC 2005


Hi Göran, Darius et al.

a) Feedback to Darius' categorisation proposal


Quoting goran.krampe at bluefish.se:

> Hmmm.... Well, having a parallell categorization... is tricky. 
Why exactly?

> The best
> would probably be if we could allow me/Darius to make categorization
> changes to existing packages. 

See my propsal below.

> We could take care recording how it was
> before our changes so that we can easily revert stuff if the owners get
> annoyed.

The author should keep his right to choose the category s(he) like.

I think the only feedback really necessary is to know if people find this list
useful.
Even the text list (hand crafted by Darius) as such on the swiki is already
useful and gives information which is not easily to get otherwise.

http://minnow.cc.gatech.edu/squeak/2000

Technically I perceive it as relatively easy to implement a solution which gives
the addtional comfort of having direct links to the individual SqueakMap entry.



b) Short outline: SqueakMap categorisation (Darius)


After you have opened the SqueakMap package loader there is a long pause during
that the clone of the SqueakMap information in your image is updated. So the
SqueakMap information is in every image (A question aside: what triggers the
reloading of the SqueakMap info?)

   SqueakMap default

works in every image which is using the SqueakMap loader.

The returned object gives access to the object net of SqueakMap information.

   SqueakMap default objects

is a Dictionary of SMPackageRelease objects. These objects have a link to their
SMPackage.

With these objects and the categorisation proposal 
http://minnow.cc.gatech.edu/squeak/2000

(basically a string) it should be relatively easily possible to create another
string with html-anchors which lead directly to the corresponding SMap-entry.
One can directly paste this html anchor string into the swiki-page.

So Darius can work independantly. Others might follow and help him or come up
with their own list of packages they find useful.



c) Categorisation policy

Regarding categorisation - I think the author should keep the right to choose
any categorisation s(he) wants. It is like putting keywords on an abstract of a
paper/book one writes.

But for people doing catalogues of software (librarians doing a kind of
"bibliography") they have the right as well to categorize the items following
their criteria. This may even include ways the authors originally didn't
intend. 

And in addition, there can be several lists/catalogues/bibliographies done by
different people. 

We are actually speaking of different 'views' of the SqueakMap object database
here (database terminology).


d) SqueakMap server
The SqueakMap server as such may or may not additional categorisation schemes.
As I outlined above even a relatively simple separate tool/script could already
generate 80% of the desired effect.

On the other hand it seems that nothing prevents us from changing the origianl
SqueakMap categorisation scheme if we agree on a better one. This has the
advantage that no additional programming is necessary. Only editing of data.
But it could be difficult to obtain the agreement of the authors (in fact it
should be a significant majority).



What do you think?

Hannes







More information about the Squeak-dev mailing list