Hi Lex!

"Lex Spoon" <lex at cc.gatech.edu> wrote:
> I am still confused.  Thanks for your patience!  I am used to a simpler

No problem!

> model (I tihnk) where you simple have name-based dependencies plus

Just for the record - I think my model is cleaner and simpler. Even
though it is different. :-)

> optional version number dependencies.  Package authors simply declare
> their dependencies in the packages.  This approach is tried and true,

I know it is tried and that it works. But it has problems. For example,
embedding the info in the package itself forces you to do a new release
of the package if he dependency information changes. That is IMHO simply
a "bug" in that scheme.

> and I think anyone will understand it.  The approach you are describing
> may well be better, but I'm having a hard time seeing how it works.

Ok, I know I should put forward arguments instead of just claims - but I
sincerely think my proposed model will be easy to understand. Btw, you
have read the webpage I recently put up with my previous postings on the
subject (well, not all postings - but the ones I found that looked
eloquent):

http://anakin.bluefish.se/gohu/17

> Before getting into it, let me toss out a little axiom of software
> development:
> 
> > > This is not true for those who have tried it.  Normally you don't use a
> > > version dependency at all.  Even when you do, you usually say simply
> > > "version >= 3.2".  It's not hard in practice.
> > 
> > Again - I think such a dependency is strange. Nobody can make such
> > promises.
> 
> There are no guarantees when it comes to software correctness.  Let us
> remember this when we discuss the "promisses" that are made in package
> dependencies.  Even if you test with a specific set of installed
> versions, there is no guarantee that the package will work on someone
> else's machine.  This axiom is so ingrained in me that when anyone
> defies it, it doesn't sound like meaningful speech to me.

In this case I gladly refer to Colin's most detailed explanation in his
response.

> Okay.  On to the questions.
> 
> First, what is a compatibility level and where does it come from, ie who
> declares it?  FWIW, there are only two styles of compabitily that seem

The person doing the release declares it. I noticed that my 6 levels of
compatibility wasn't explained on the webpage referred to above. And I
can't find my emails on the subject either. Ok, let's see if I remember:

1 = No change actually, just better class/method comments, method
categories etc. Note that this level can actually be "machine verified"

2 = There have been additions but no changes to existing code (added
methods and classes for example). Old clients should be unaffected. Note
that this level can actually be "machine verified"

3 = There have been changes but only "refactorings" and bug fixes.
Nothing that should (but of course theoreticall still *can*) have
effects on other objects given the encapsulation of Smalltalk.

4. = There have been changes in behaviour of the objects but the public
APIs should be unaffected.

5. = There have been changes in behaviour of the public APIs but older
clients should still work fine.

6. = The public APIs have changed. Old clients have chance to work if
they don't use the changed parts.

7. = The public APIs have changed so much that old clients don't stand a
chance of working.


Ok, this time they turned out to be 7! :-) Anyway, don't regard the
above list as anything else than something to discuss. I haven't thought
through these levels too much. As you see these levels are "to the best
of the maintainers knowledge" (at least 3-7) and are always relative to
the previous release of course. Also note that the level from version
1.0 to 1.3 would simply be the "max" of the levels of 1.1, 1.2 and 1.3.

> to come up in practice; I can think of no exceptions:
> 
> 	1. There is no compatibility.  The package is under intense
> development.
> 
> 	2. There is upwards compatibility within major versions.  If your code
> works with 3.5, then it will work with 3.6, 3.7, etc.  No guarantees for
> 4.3 however.
> 
> I wonder if a checkbox would suffice?

Well, hopefully given my list above you can agree with me that there are
finer levels to consider.

> Second, how do you know which packages to mention in a tested
> configuration?  Surely there is a list somewhere in the package's
> meta-info about what packages are relevant.  You aren't going to include
> every package the image includes, surely.

The maintainer know what packages to list. Other posted configurations
will probably tend to be variations on those. But that depends on how
deep knowledge the person has about the package.
 
 
> Third, what do you plan to do with tested configurations?  In
> particular, what happens if some people use only the newest libraries
> and some do not?  Then the server ends up with this pile of
> configurations that users have to select among.  Are you certain that
> you cannot get in the situation where one package is only tested with
> RePlugin 3.5 and another is only tested with RePlugin 3.6?  What do you
> do in this case?

I think that the model will put pressure on packages that haven't been
tested (or have been tested and verified to not work, or simply hasn't
been updated to be able to work) so that they too use the newer releases
available of the packages that will have many dependents (like Comanche
or RePlugin).

Furthermore, how to select among the configurations will be up to the
user and the engine. Since configurations as well as packages and
packagereleases will be categorizable (as packages are today on SM) we
can easily make priorities. All of these three SMObjects also have a
maintainer and different trust models can be used, like for example
"Only trust configurations published by the package maintainer" or "Only
trust configurations published by people I trust" etc.
 
> Fourth, can you try again to explain how you'd have an abstract
> webserver interface, or an abstract smtp-client interface?  The simple
> model I am familiar with allows packages to include declarations for
> abstract interfaces that they provide.  Thus, Celeste can declare
> "Provides mail-sending-client", and packages which depend on
> mail-sending-client can grab Celeste if they want it.  It's extremely
> simple.

I think Colin did a good job on a rather simple scheme here. We could of
course add some form of "Provides yaddayadda"-mechanism but I want more
discussion around this particular area before adding another mechanism
into the mix. Colins proposal sounded extremely simple.

> You mention the worry that one package's mail-sending-client might be
> different from another, but that is just as much of a bug no matter how
> the mail-sending-client API is documented.  Including a concrete package
> named mail-sending-client does not get around the fact that one or the
> other package might have a buggy or inconsistent implementation.  This
> gets back to the axiom of no warranty I mentioned to begin with.

I didn't (I think) talk about buggy implementations. I worried about
*different versions of the API*. Having a proper package to depend on we
also get versions of that package (what I call package releases) to
depend on.
 
> > What I truly meant above is that it gets much harder to analyze. My
> > model will (Something I believe after making scenarios and playing
> > around with lots of arrows and circles :-) hopefully fit pretty nicely
> > with an engine that can - given a list of needed packages or package
> > releases - compute what I need to install. I still stand by the fact
> > that having a model with boolean algebra and operators makes it much
> > more complex.
> 
> Maybe it's more complex (I have no idea), but it's proven to work just
> fine in practice, so it is not so complex that it cannot be implemented.

Fine. Then why don't you implement it. ;-)

As I said - SM will not force any particular model on to the community.
Anyone can take the chance NOW to step up and say "Hey! Your proposal
sucks! I will implement my model instead!". And I would then gladly let
that someone do it.

Of course - you would need to wait a week at least so that I get the
time to get the the alpha version of SM1.1 up on display but that would
be ample of time to prepare and present a model to the community. :-)

>  Also, remember that in practice almost all the requirements are either
> empty, or are of the form "version >= x".
> 
> > Given SM1.1 we will have the ability to build the dependency engine as a
> > separate tool. This is because I want SM to be targeted and tight - I
> > don't want it to "handle evertyhing" and when I realized that it should
> > only deal with maintaining a distributed model of package
> > metainformation then I also realized that a dependency model + engine is
> > just a client of on top of that model.
> > 
> > SqueakMap is just the map.
> 
> Well, I would hope that in the future the standard SqueakMap client does
> in fact handle dependencies correctly.  Also, I hope it is possible to

Definitely! But I repeat - SM itself will not include the dependency
engine. It will be a separate package and will easily live on the client
side. This will of course not be known to users but it will make it much
easier to implement and play around with.

> download all the package metainfo in batch, so that the standard client
> can do smart things.  But anyway, this is all just moving the dirt

Since the dependency info will be put into what I call "embedded
resources" (essentially Strings attached to the package releases) it
will all be there right inside the map. No batch loading required.

> around.  Everyone wants dependencies, and there is a question of what
> they should look like.

Indeed. And I have been posting on the subject on and on and only a few
have piped up with ideas and criticism. But as always - the closer you
get the more interest. ;-)
 
> Okay, let me toss out one more query, to add to the one about abstract
> packages.  Do you have any ideas about *conflicting* packages?  For

Honestly I haven't given them much thought but Colin's posting sounded
good. Anti-configurations. :-)

> example, you may only be able to load one top-level GUI package
> (SCMorphic or MorphicWrappers) at a time.  Or, a new package may be the
> union of two older packages, and thus you can't load the newer package
> while either of the older ones is loaded.  With dependencies, you can
> add other kinds of dependencies, in this case "Conflicts with foo and
> bar".
> 
> (Yes, the algorithm grows more complex, but again, it only has to be
> implemented once, and it has been implemented in other contexts.)

Well, Colin's anti-configs sounds rather easy. I don't think it would
make the engine terribly much more complex.
 
> Cheers,
> 
> Lex

Cheers, Göran