Goran,
I didn't mean in any way to call your baby ugly, but it *IS* just a database with a user interface that makes it easy to do useful things, and from a USER point of view (as opposed to a package PUBLISHER or DEVELOPER) it is simply a tool for importing new code into a local image. That is what I mean by monolithic image based. The fact that SM supports multiple file formats is wonderful, but that really has nothing to do with the structure of the underlying source code.
Unless I've missed something, once you use SM to import a package into an image, there is no easy way to "undo" this package addition. This is also consistent with the "monlithic image model".
Please don't misunderstand. I'm not attemtping to criticize any any of the great work being done in Squeak. Microsoft, I am criticizing, but not Squeak or Squeak contributions.
If anything I was trying to make the point that flexibility does not come for free, and that I prefer Dan Ingalls's original premise of "the simplest thing that could possibly work".
-Dean
-----Original Message----- From: goran.hultgren@bluefish.se [mailto:goran.hultgren@bluefish.se] Sent: Thursday, October 31, 2002 3:42 AM To: squeak-dev@lists.squeakfoundation.org Subject: RE: An uncomfortable question
Hi all!
"Swan, Dean" Dean_Swan@Mitel.COM wrote: [SNIP]
And regarding SqueakMap and DVS, realize that these are based on the monolithic image model. They are more or less fancy user interfaces to manage filing in the various change sets (I know I'm oversimplifying a bit, but the point is still valid).
Well... No, I think you are oversimplifying a bit too much. SqueakMap is a distributed catalog of packages that can be installed into a Squeak image. It is already supporting different package formats:
-.st, .cs, .st.gz, .cs.gz (Simple fileins as you mention) -.pr (Implemented but not released) -.sar (Neds new megaformat capable of anything, probably similar to debs, rpms) -.st DVS (Avi's DVS .st format which both can be filed in conventionally AND filed in using DVS thus making a package more or less upgradeable)
My point here is that SM doesn't just handle changesets but any package format. And when the package formats evolve further we will start seeing new ways to deal with them - like a controlled upgrade for example. Or uninstall.
I am not sure what you mean with "based on the monolithic image model" but IMHO SqueakMap together with DVS etc is changing this. As a small example, very soon Celeste can be cut out of the image and be published on SM - I think Daniel is itching to do that and we already have all the tools that it takes.
In fact SM itself is probably (this is the current proposal) the very first package that is NOT going into the image! Yep, eating my own dogfood. For the curious this means that when SM hits the update stream for 3.2 (we are hopefully talking days now) it will actually only be a little bootstrap script going in - not SM itself. What does this mean in practice?
It means that when you update 3.2 you will get a chance to install SM into it "by remote". As the user you will not see the difference but for us package developers it is a huge difference. The SM code that you now have in your image is NOT maintained using the regular update stream. It is maintained outside of the image. When I (being the maintainer of SM) integrate new fixes etc and decide to release a new version of SM I can do that independently and you will be able to upgrade (from within SM) SM itself when you decide to, also independently of other packages.
In short, packages published in SM (including SM itself) have their own maintainers, their own "updatestreams" and their own place of storage on the net - so they are completely independent of the image.
Of course, monolithic systems have the issue of shared namespaces which can make it difficult to make different packages play nice together in the same image, so like I said, the problem is non-trivial.
Yes, namespaces etc is cool and we will probably end up with it sometime. But we don't need to solve all problems at once - simple class name prefixes go a long way.
SqueakMap does work pretty nicely already - and we all know things are missing but we are working on it. The next big step for SM will probably be versions of packages and handling dependencies (in some way - there are different ways to do it) between them. Before that though I want to wrap up the extensions sent to me from Ned and Avi, smack down on a few silly bugs and get 1.0 out the door.
regards, Göran
Sorry for not responding earlier - I missed this one. I use Celeste and sometimes when people have different time on their computers the mails don't end up "last" in my inbox.
"Swan, Dean" Dean_Swan@Mitel.COM wrote:
Goran,
I didn't mean in any way to call your baby ugly, but it *IS* just
:-) No offense taken.
a database with a user interface that makes it easy to do useful things, and from a USER point of view (as opposed to a package PUBLISHER or DEVELOPER) it is simply a tool for importing new code into a local image. That is what I mean by monolithic image based. The fact that SM supports multiple file formats is wonderful, but that really has nothing to do with the structure of the underlying source code.
Unless I've missed something, once you use SM to import a package into an image, there is no easy way to "undo" this package addition. This is also consistent with the "monlithic image model".
That depends on the package format for the particular package. For example - if you use DVS package format you can already do a controlled upgrade. No uninstall yet though, but I actually think upgrade is more useful. You can always pick a clean image and then reinstall all the packages you want.
We could also very easily introduce an installer that could install and uninstall "class libraries" - .fileins that simply has a bunch of classes with no loose methods and do-its and no class initialization that affects something else than the classes themselves.
And if you use a .pr package format then... well, I don't know much about Projects but I think they are fully uninstallable, but "uninstall" is not something we are tackling yet. We will probably try to tackle "upgrade" and "reinstall" better first.
Please don't misunderstand. I'm not attemtping to criticize any any of the great work being done in Squeak. Microsoft, I am criticizing, but not Squeak or Squeak contributions.
:-) I don't misunderstand, don't worry.
If anything I was trying to make the point that flexibility does not come for free, and that I prefer Dan Ingalls's original premise of "the simplest thing that could possibly work".
I also like that concept. And that is actually something we try to follow with SM. We are very focused on doing it all in small steps. We don't really need namespaces to be able to have packages. We don't really need new package formats either.
Believe it or not - we can today using plain old .cs and .st formats possible with DVS in the mix come pretty far.
Anyway, I think it all boils down to what problems you want to solve - let's stick to talking about those (discussing the meaning of monolithic doesn't really move things forward):
Would you like to have namespaces and the ability to install different versions of the same package at the same time? Hey, SM and DVS etc are not even trying to solve those problems.
On the other hand, would you like to cut out pieces of the image like Celeste, IRC and Scamper into easily installable packages of their own? Would you like to publish your own package independently of what other people think of it? Would you like to have distributed maintenance of these packages? Would you like to easily find and install the latest available package X? Would you like to move the image towards a small kernel and have the rest as installable packages on top of it?
All these problems and more are solvable *today* using SM (and DVS in some areas). He, what a sales guy I am... ;-)
regards, Göran
squeak-dev@lists.squeakfoundation.org