Components:

I picture a Component as an independent system that I can send messages
to.  Each message may cause changes in the data I refer to in the
message, cause changes in the component itself, cause messages to be
sent to other components, and/or cause result data to be returned.  Data
(message arguments and results) are trees of data records, aka, objects
but without predefined behavior.  Receiving components define their own
behavior for each type (class) of record.  If a component sees a class
it does not know about it raises an error.

Eliminating behavior from message arguments/results decouples
components, allowing them to be changed independently.  They only have
to agree on record format and class identity.  But unlike traditional
stationary systems, components can expand and migrate across machines as
necessary (like a blob).

If two components reside in the same Squeak image then sending messages
between them just involves pasing object pointers (like normal object
sends).  But if they reside on different machines then sending messages
involves encoding the objects into an image segment stream, sending it,
and then decoding it on the other side.  Furthermore, to maintain object
identity only remote references of objects can be passed, however, free
(about to be garbage collected) and immutable objects can be passed as
whole objects.  When a component wants to execute a method on a remote
object it received from a remote machine, it loads a copy of itself on
the remote machine and executes its method there, where the object
resides.  Changes to component globals/behaviors are kept in synch
across machines.

Packages:

If the remote machine already contains some of the behavior that is
needed by the migrating component, it would be nice if it could reuse
that behavior, without loading a redundant copy.  This is where packages
come in.  A Component is an environment that inherits from one or more
immutable packages.  A Package is a set of immutable globals, behaviors,
and inherited packages.  Packages are layered, so a package may override
a global/behavior defined in one of its inherited packages.  A package
has a single name space that includes all the names of its inherited
packages.  Ambiguities in inherited names are explicitly resolved by
overriding the effected objects with new names.

So when loading a component, the Squeak image only needs to load
packages that are not already loaded (for other components).  A
component is really just a mutable package, it has its own
globals/behavior that add to or override the packages it inherits from. 
A component has a single name space, but because it can reference other
components and get objects from thm by sending messages to them, you
basically have nested name spaces as well.

Conclusion:

In today's Internet world, we need a modular solution that directly
addresses distributed Squeak systems as well as the traditional building
of custom local systems.  The current Project class stuff could work
well in a distributed component architecture like the one described
here.  Components are isolated and are quickly migratable if immutable
incremental packages are used.

Inheriting fixed immutable packages are preferred to inheriting a range
of versions or inheriting a changeable package because otherwise a
single distributed component could behave differently depending on what
machine its executing on.  Changes to a components behavior
would involve creating a new incremental package that inherits from the
old packages and then updating the component to inherit from the new
package.  This change would automatically be propogated to other
machines where the component is loaded, causing the new package to be
distibuted to the other machines automatically.  And since components
are isolated, it would not affect other work.

Objects are easily convertable to components and vise versa.  If an
object and related objects do a lot of work that is pretty well separate
from the rest of the system, and sends relatively few messages to
arguments coming in on messages sent to it, then the object is a good 
candidate for becoming its own component.  Senders would not have to 
change at all.  You just have to make the object a subclass of Component, 
and then make sure it inherits from the package(s) that defines the 
messages you send to arguments and other objects your component points 
to.  Some analysis tool could help with this.

I hope this make sense to some (hopefully most) of you.

Cheers,
Anthony