GREAT.
Continue continue continue...

On jeudi, octobre 31, 2002, at 09:41  am, goran.hultgren at bluefish.se=
=20
wrote:

> Hi all!
>
> "Swan, Dean" <Dean_Swan at Mitel.COM> wrote:
> [SNIP]
>> And regarding SqueakMap and DVS, realize that these are based on t=
he=20
>> monolithic image model.  They are more or less fancy user interfac=
es=20
>> to manage filing in the various change sets (I know I'm=20
>> oversimplifying a bit, but the point is still valid).
>
> Well... No, I think you are oversimplifying a bit too much. SqueakM=
ap=20
> is
> a distributed catalog of packages that can be installed into a Sque=
ak
> 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=20
> conventionally
> AND filed in using DVS thus making a package more or less upgradeab=
le)
>
> My point here is that SM doesn't just handle changesets but any pac=
kage
> format. And when the package formats evolve further we will start=
=20
> 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 mod=
el"
> but IMHO SqueakMap together with DVS etc is changing this. As a sma=
ll
> example, very soon Celeste can be cut out of the image and be publi=
shed
> on SM - I think Daniel is itching to do that and we already have al=
l=20
> the
> tools that it takes.
>
> In fact SM itself is probably (this is the current proposal) the ve=
ry
> 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 st=
ream
> for 3.2 (we are hopefully talking days now) it will actually only b=
e a
> little bootstrap script going in - not SM itself. What does this me=
an=20
> 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 bu=
t=20
> 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 strea=
m.=20
> 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 stora=
ge=20
> on
> the net - so they are completely independent of the image.
>
>> Of course, monolithic systems have the issue of shared namespaces=
=20
>> which can make it difficult to make different packages play nice=
=20
>> together in the same image, so like I said, the problem is=20
>> 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=
=20
> 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=
=20
> probably
> be versions of packages and handling dependencies (in some way - th=
ere
> are different ways to do it) between them. Before that though I wan=
t 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=88ran
>
>
>
Dr. St=E9phane DUCASSE (ducasse at iam.unibe.ch)=20
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes