> > It looks pretty good but there are a number of aspects that 
> > I don't really like too much.
> 
> Sigh... ;-)

Well, that's user interface design ;-) You do something criticize it and do
it again.

> > One is a conceptional problem: Unless we have cards for each
> > individual version of a package, updating an SM card from 
> > the server would lead people to think that there's a new quickstart 
> > available. Clicking on it would result in DNU unless they do have
> > the very latest (very bad in the light of active development).
> 
> True. In SM1.1 this will not be a problem. There resources are linked
> with package *releases* and not packages (well, can be linked to
> packages too but in this case it would be dumb).

Interesting. Does this mean the annotations are more tightly integrated
within SM1.1 than they are right now? Can you say a little more about the
anticipated model we're following here (it may well be that I am just
criticizing things that'll be solved by 1.1 implicitly)? I was under the
assumption that these annotations would be pretty much "per package" as they
are right now.

> That was the idea of course - I just wanted to show it can easily be
> done. It was not a serious ENH - more like a prototype to play with.

I fully understand this ;-) Similarly, my critique was more along the lines
of "okay, I kinda like this but..."

> > for the attributation which makes it simple for the package 
> > maintainers to link external documentation into the UI. In addition
> > to this, I still think
> 
> Well, again - sure. In thinking forward an SMResource can either be a
> String (and be embedded in the map) or be a URL which of course can
> point to anything like the examples above. And again - they would be
> linked to package releases.

That would be terrific.

> Well, on the other hand I don't want a package to force feed my image
> with unit tests, examples, tutorials, documentation etc. when I don't
> need it.

Well, that wasn't quite my point. It was more aimed at "release specific"
information. If SM 1.1 is able to deal with it this wouldn't be a problem at
all. I was just thinking that when you do development it would be a shame if
projects which are actively documented would break first.

> Yes. Fudging with special markup etc inside a description is a "hack".

Do you have a more elaborate mechanism for this already worked out?

Cheers,
  - Andreas