Re: against the components utopia

On Mon, Feb 13, 2006 at 03:33:17PM +0100, Lex Spoon wrote:
> I see no conflict between sbaz and Kitten.

There's none at all. They have quite different purposes. Kitten is
only interested in loading components together and managing them at
runtime.

> Sbaz itself is agnostic
> about what kind of components are shipped around and the mechanism by
> which they are linked into a running program.  So, by all means feel
> free to post Kitten tools and Kitten-packaged components to the
> scala-dev bazaar!

I'll hopefully be able to put some sort of standalone 'quick start'
version of Kitten in sbaz, but a production installation will need to
be packaged for the OS. I'm not sure if sbaz makes sense for Kitten
components, since they are just single zip files and the user will
want to manually deploy them into a given kitten instance.

That's a little way off though; it's going to be a few weeks at least
before we get some breathing space to migrate to Scala2 (we're still
on 1.3.0.10; we could never get our code to compile on the 1.4
series), and I have a fair amount of work to do before the next
release.

> > AIUI, in sbaz there are two options: modify the source of the package
> > to work in the universe, or create a new universe. The first is of
> > course the ideal solution, but it may not be feasible, either because
> > the source is not available, or because there is not development time
> > spare to do the conversion. The second option I consider unworkable:
> > what if I need one of the packages that can't fit into this new
> > universe?
> 
> With sbaz, the straightforward approach would be to use a custom
> CLASSPATH.  For politeness, you should not, in that case, put the
> conflicting jar's into /lib.

Unfortunately that's not enough. A classpath will always only let you
load one version of a given package. If you need more than one
version, you need separate classloaders.

> Have you looked at "Jiazzi" at all?

I looked at it briefly a couple of years ago. I get the impression
that it accomplishes much the same thing as Scala's built-in
mechanisms, though less invasively.

My focus is much more on managing components at runtime, handling
situations such as hot redeployment. The dependencies issue is more of
an annoyance than a design focus. I'm hoping to avoid dealing with
anything more fine-grained than whole packages.

> On the first question: not necessarily.  While for many people it is
> possible to work in a corner of an existing universe, for others
> obviously it is not.  Google is not going to post their code to a
> public Gentoo server even if they use the Gentoo tools.

I'm not arguing against universes from the point of view of
package distribution or release policies. Going back to Debian, it
makes perfect sense to have separate unstable and stable branches, and
of course many people run their own public or private repositories.

The issue I have is that the unstable and stable branches are
incompatible. You can't mix them. That's pretty much unavoidable for
Debian because it uses native binaries, but it /can/ be avoided for
Java and Scala /provided/ there's code in place to deal with
occasional incompatibilities when they do occur.

-- Jamie Webb