[Squeakfoundation]A bit about SM1.1 and dependencies

[goran.hultgren at bluefish.se]

Hi!

I sent this email to Avi, Ned and Chris Muller as a response to Chris
wonderings but then I thought I could post it here too. If you are
interested in dependencies this might be interesting to read. It is
about my plans for SM1.1 and beyond.

regards, Göran

-----

Hi Chris and all!

Chris Muller <afunkyobject at yahoo.com> wrote:
> --- Ned Konz <ned at bike-nomad.com> wrote:
> > Note that the prerequisite handling in SARs is only 
> > temporary, until SqueakMap gets dependency handling.
> 
> Hmm..  I'm a bit confused by this.  It seems to me that dependency definitions
> would be something more at the Package level.  Thinking out loud - Packages

It typically is in for example RPM or deb. But that is not my current
plan. :-)
Well, "not really" anyway. As you will see below default information
could redundantly be included in the SAR, but it should still be
available separately.

> have additional resources, readme's, change histories and dependencies. 

Yes.

> SqueakMap, on the other hand, is a cataloging system.  It knows *where*
> packages are, *who* maintains them and, for my convenience, obtains the stream,
> local or network, necessary for SarInstaller to do the installation work.

Right.

> So if prerequisite handling is removed from PackageInfo's and SAR utilities,
> then does that mean the only packages that'll be able to have prerequisites are
> ones cataloged in SqueakMap?

Eh, no. It could be included inside. But in order to have an engine be
able to reason about dependencies without having to download the
packages themselves this information should *also* be available
separately. An URL will be sufficient.

> Please educate me..

Ok. :-) Unfortunately I haven't written down my plan for the upcoming SM
in a detailed manner - so it is not "your fault" not knowing about this.
:-) I really should do this. Perhaps I will find some time for that
later this week. Anyway, here goes:

In regard to dependencies (there are other things coming in SM1.1 too,
but that is of less importance here) I am in SM1.1 adding these
mechanisms:

1. Package releases. In SM1.1 you will first register a package much
like you do today, but much of the information will instead be entered
for a PackageRelease that the Package owns. So the url, the version
info, the version name etc etc will be attributes of PackageRelease
instead of Package. This is just simply necessary for us to be able to
handle dependencies since they must be between specific releases of
packages and not just the packages.

2. Links. All things that can be registered on SM1.1 will have a "link
list" to other things registered at SM. This way a Package can link to
another Package typically just to give guidance or whatever. But it is
also a crucial capability for handling dependencies - see below.

2. Resource. This is a new beast in SM1.1. It is simply a digital
resource given by a URL that is not a Package or a PackageRelease. So
Resource will be the "kitchen sink" type that we can use for whatever we
like. This way we can create new kinds of "additional info" and attach
them (by using Links) to Packages or PackageReleases.


Ok. This is actually the only ground work I aim for in SM1.1. But hey,
you say. Where are the dependencies? Aha! SM doesn't really know about
them! BUT... we will be able to create dependency information and
"attach" that information to the PackageReleases using the Link/Resource
mechanism described above.

Given this here is my plan for dependencies that I discussed at length
at OOPSLA with Roel Wuyts, Ned Konz, Doug Way and many more - especially
Daniel Vainsencher on email:

On SM anyone can register a "Package Configuration" as a Resource. This
is simply a list of specific PackageReleases of other prereq packages
that a given PackageRelease of package X works with. This resource is
then associated with the PackageRelease in question. Typically the
maintainer of package X would register at least one such "working
configuration".

Note that the dependency information is NOT inside the package. There is
nothing stopping the package maintainer of having the same "default"
configuration inside the SAR of course in order to make the SAR file a
bit more "self sufficient".

But the main point here is that the maintainer of package X is not the
ONLY one that can register package configurations for package X. If I
find out that, hey - Magma works just as well together with package Y
version 1.13 as a replacement for package Z 3.4 then I can register that
configuration as a viable alternative.

Note that the registrant is visible so perhaps nobody trusts me in
regards to Magma, in that case they would pick Chris suggested
configuration instead.

Anyway - now the field is open. We can now construct a simple textual
format (I would simply use Smalltalk) for these "Package Configurations"
and then someone can build a really cool dependency resolution engine to
answer the question - "Ok, I want the newest Seaside, Magm, YAXO and
SIXX that work nicely together."

It would then build a dependency graph and do all sorts of smart
reasoning and hopefully come up with a nice list of Package Releases
including all non conflicting prerequisite packages.

The cool part of this plan is that we have maximum flexibility, SM
doesn't really know anything about dependencies (as it should not),
different models for describing dependencies and different resolution
engines could be tested and of course - the change in known dependencies
does NOT force a new package release!

By the way - the SM1.1 servers should be able to "mirror" the resources
registered simply by downloading the URLs given to the server.

I hope this helped a bit.

regards, Göran

PS. Perhaps I should post this somewhere...