Anthony Hannan <ajh18 at cornell.edu> wrote:
> Proceeding incrementally is fine, but I still think we need to discuss
> and decide which final "elegant" package design we want.  Then we will
> have a goal that will provide a road map for the incremental changes,
> and avoid incremental changes that may later be harder to adapt to the
> goal.

Well, I agree that discussion is good. Otherwise I wouldn't reply! :-)
But I also think that "just doing it" is also good - we learn by doing
and Grand Plans that aren't implemented are *by definition* inferior to
Simple Solutions that are.

> My point in my last message about being object-oriented is that "meta"
> data about packages and the packages themselves should be merged into
> single package objects.  Just having some "meta" data available for query
> is not good enough.  What if I want to find all packages that implement
> or send a particular selector.

Define "is not good enough". :-) For many of us it actually is. And for
the whole Debian community which is LARGE and has over 1000 package
maintainers and over 10000 packages it also seems to be "good enough".

> I understand the nice thing about separate "meta" data is that it allows
> just the "meta" data to be loaded without the rest of the package.  But
> this is a problem that can be better solved with an object database.  It
> could load just the package objects without loading its classes until
> they are needed.  And object database is also beneficial in other areas
> as well.  So, we might better utilize our efforts in pursuing a general
> object database solution instead of a specific package files solution.

I know lots about OODBs having worked with GemStone/S, GemStone/J, Poet,
Tensegrity and perhaps one or two more. They are very cool. I love the
work Stephen Pair and Chris Muller are doing.

But... There are conscious design decisions made here:

- SqueakMap should be simple even for newbies to understand. So the
approach should be simple.
- SqueakMap shouldn't depend on any large complex packages itself. It
needs to run at least on the current image. This ruled out Magma or othe
complex software.
- SqueakMap should work offline.
- SqueakMap should work on small computers like a PDA.
- SqueakMap should be robust. (And apart from the silly UUID accident it
seems to be - this is a lot due to the simple approach taken)
- SqueakMap should be effective. (Loading updates is fast both on the
server and the client due to the design)

Just so you know I didn't make a "naive" implementation because I am
"naive". It was in many ways intentional. :-)

And finally - I can probably explain how SqueakMap works to a newbie
with very few problems. The code is very small. This is very important.
PIE, 3.3alpha Modules and similar "high tech" solutions can actually
fail just because they are too "smart" and too "complex".

Again - where is PIE? What year was it built? SM was built this year and
is used now. The KISS principle.

But let me assure you - I have also been thinking about for example
having an online database to be able to answer queries like "all senders
of" etc. And I have also dwelled upon the decision to have meta data
outside of the packages (and currently I think it is a good move
actually, ask me for more details and I can explain more).

And Traits would be really cool to have. On *that* I agree! :-)

regards, Göran

PS. When we actually have an OODB inside Squeak that is proven etc
perhaps we can move to using that - the SM model is still just a simple
objectmodel.