"Andreas Raab" <andreas.raab at gmx.de> wrote:
> > > 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.

Indeed. Just kidding.

> > > 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

Now? Annotations? I am not sure what you mean. AFAIK there are no
annotation mechanism today.

> 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.

Nope. They are in fact per SMObject. And in SM1.1 it looks like this:

SMObject #('id' 'map' 'created' 'updated' 'name' 'summary' 'url')
			SMCategorizableObject #('categories' 'links')
				SMAccount #('initials' 'email' 'signature' 'password' 'newPassword'
'personalObjects')
				SMPackageRelease #('publisher' 'automaticVersion' 'version' 'note'
'downloadUrl' 'package')
				SMPersonalObject #('account')
					SMDocument #('description' 'author')
						SMPackage #('releases')
						SMResource #()
							SMEmbeddedResource #('content' 'version')
							SMExternalResource #('downloadUrl')
			SMCategory #('mandatory' 'subCategories' 'parent' 'objects')

The "links" instvar in SMCategorizableObject references other SMObjects.
So this means SMAccounts, SMPackages, SMPackageReleases,
SMEmbeddedResources and SMExternalResources can have links to other
SMObjects. Typically the links refers to SMResources.

> > 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..."

Goodie!

> > > 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?

Nope. Unless you are talking about the halfcooked SM1.1 on my hd. Next
week will contain quite a lot of SM1.1 hacking - hopefully by the end of
it a working alpha server will be up.
 
> Cheers,
>   - Andreas


regards, Göran