Hi all!

Daniel Vainsencher <danielv at netvision.net.il> wrote:
[SNIP of things I agree with]
> Another thing is that I think our first concern should be *user*
> documentation, that covers the trivial initial aspects of how to get
> some idea of what the software does, as opposed to code documentation.
> The original impetus for this thread is really about the whole end to
> end process of sharing software -
> 1. You need to hear that it exists
> 2. You need to find a packaged, recent version
> 3. Fulfill the dependencies
> 4. Load
> 5. Figure out what button to press to get the initial GUI.
> 6. Understand how to operate it.
> 7. Start learning the architecture.
> 
> SM effectively solves 1, 2, 4. 
> SM 1.1 will help with 3.
> If someone gets to 7, we've practically won already.
>
> Our battle is for 5 and 6. The problem is that if the user cannot
> estimate how long it will take him to understand a package, he may
> decide out of hand that he doesn't have time to experiment today. This

For 5 & 6 I want to use SMResources in SM1.1 but the just posted hack
(QuickStartMenu) does the same job - but by stuffing stuff into the
description field. We can still play with it and see if it feels nice.

One nice property with this hack (compared to a registry) is that we
avoid the problem of "naughty apps" that doesn't maintain the registry
correct (forgets to register or forgets to unregister, or simply does it
wrong etc). The hack only relies on state in the map.

> is why I initially wrote that the initial documentation should be in the
> SM entry in the description field. I accept Andreas' comment that the SM
> entry can also merely mention that a how-to exists, but I think having
> at least this is crucial, and requires no general agreement or code. If
> you agree with the above, and care about people using your packages, fix
> your SM entries.

Generally true, yes. People tend to only read a couple of lines and then
give up. :-)

> [Andreas mention that SML is bad for loaded packages]
> First, I've had suggestions before that SML should have a "loaded
> packages" pane, though without very precise requirements for them. I'm
> becoming convinced. OTOH, I think it is important to delimit what SM's
> role is - I think it should be just about managing content installation
> in the image. I say "content", because I don't think SM should be either
> limited specifically to code, or specialized to a certain idea of code

I agree with the "not limited" part. I am not so sure I agree with
"content" versus "other things", see below.

> (for example, SM should not know about MC). Systems that try to do too
> many things, and are not clear about where their limits are tend to lose
> focus of priorities, and not do even one specific thing well, and I'd
> hate for this to happen to SM. The content installation space is big and
> complex as is.

I agree. The current SM uses SMInstaller classes to hook into other
mechanisms like Monticello or DVS. I would much rather like to have
dynamic hooks instead of code. But I put that on hold.

> To get back to the issue at hand, I don't think SMs "installed packages"
> pane should be the place where people expect to find the true contents

This is where I am starting to itch.

> of their image. One reason is because people will still install stuff
> using regular file ins, and specialized tools such as MC, and sometimes
> it may not make sense to not this in SM.

Yes, but my view is rather the opposite - wouldn't it be better to have
a single place to keep track of all kinds of installations?

> Consider code that doesn't yet
> correspond to an SM entry to be an example. 

Yes, that is a "problem". Either we solve it by making SM handle such
non listed packages. Like apt-get/rpm can. Or we simply move the
installation registry out of SM into the image somewhere else.

But to have two places feels confusing.
 
> I we do want some central point of access to everything I have installed
> in the image, I think we should think about something new that will fill
> that role. If we start with Andreas' idea of another dynamic menu, for
> example, it might be a good idea for this to be a dynamic registry that
> allows the registration of various kinds of objects - PackageInfos that
> represent a specific code without other context, changesets that
> represent raw fileins, SMEntries for SM installed stuff, MCPackages, and
> so forth. 

I can agree with this but only if we then at the same time remove the
registry currently in SM. Otherwise there would be two places.

> One of the options that these entries could contain is documentation.

Sure. Even though somehow it would feel simpler to make SM capable of
containing "non listed" installed packages. Just as apt-get/rpm can. I
mean, this was after all the idea with SM.

> Daniel

regards, Göran