On Oct 31, 2007, at 7:51 PM, Chris Muller wrote:

> SqueakMap supports SAR files, which can do *anything*.  Therefore it,
> too, supports dependencies.
>
> To me, the process of building an image is something that always needs
> to be done with care.  A tool that tries to pick "the most recent
> versions" of prerequisite packages, to me, is "gunslinger" style of
> building an image.
>
> What exactly does "guaranteed to work together" mean?  This is a
> notion I never really followed about Universes.  Does it simply mean
> what SqueaMap already tells us?  That neither of the packages does any
> modifications to the base image?  "Work" has different means for
> different people depending on the needs.  If loading one package
> causes a slow-down in the performance of the other that matters to me,
> how can it be said "guaranteed to work?"
>

Hi Chris - I think you are missing one of the main points of the  
Universe model. Universes do not pick the "most recent version of  
anything. A particular universe has pointers to specific code  
packages, i.e. specific mcz files which represent one and only one  
version of that piece of code. There is nothing dynamic about it, so  
it is really like a freebsd port or debian package - you have to have  
specific version of the dependencies that port or package needs, not  
just the "latest".

"Guaranteed to work together" means that the author of the Universe  
has ostensibly tested that the specific package versions in that  
Universe do in fact work together. Since it is NOT grabbing "the  
latest code", that is a claim a Universe can make.

Of course, nothing prevents someone from creating a Universe and  
putting incompatible packages in it and not testing it; the purpose,  
however, is define a cohesive set of code that does work together.

I think the fact that most Universes published have a great deal of  
code in them is a bit misleading as to the purpose of Universes - for  
example, if I have a seaside web app that I want to deploy, building a  
universe that contains the specific version of Kom, Seaside,  
Scriptaculous, Magritte, etc. that is a working, stable application  
makes great sense. Someone can load that Universe and expect it to work.

Later I can create a newer version of Universe with newer packages in  
it - someone can load the new one or the old one, it's there choice.






> This is why I used the strong word "misguided".  It is not intended as
> a criticism of the technology, maybe more of the marketing..
>
> Stef wrote:
>
>> the intention being universes is to have a kind of certified release
>> which is really valuable.
>
> By "certiifed" do you mean an assessment of the level of quality?  If
> so, SqueakMap has this too ("Solid as a rock" ... "Full of bugs for
> developers only).
>
>> Since lot of squeakmap packages do not indicate really if they work
>> on not in a given version.
>
> A given version of Squeak?  Yes it does.  They all indicate what
> versions of Squeak they are for, and when you load it you get a
> warning if your version of Squeak does not match, but still allowing
> to proceed at your risk.
>
>
>
>
>
> On 10/31/07, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
>> On 10/31/07, Chris Muller <asqueaker at gmail.com> wrote:
>>>
>>> SqueakMap is a great Squeak legacy and
>>> allows stuff to be loaded into a clean image.  Universes, to me,
>>> sounds a bit misguided, and far from making rendering SqueakMap
>>> obsolete.
>>
>> I'm confused here.  As far as I know:
>>
>> SqueakMap is a tool that allows one to load a package into an image
>> Universes is a tool that allows one to load a package into an image,
>> but is more sophisticated (e.g. understands dependencies).
>>
>> Please correct me if I'm wrong, because by that definition SqueakMap
>> appears to be clearly obsolete from a technical point of view.
>>
>> Note, I'm only speaking to your statement about Universes being
>> misguided and not rendering SqueakMap obsolete.  The nostalgia of SM
>> and the purpose it serves as a record of anything ever done in Squeak
>> are a separate concern.
>>
>