local SqueakMap's (was Re: Feedback)

[Lex Spoon]

In general, Goran, this sounds like a plan that can work, if you want to
do all that work!  Let's just keep our eyes on the list of desiderata
(local development, dependencies, and whatever else), but if they are
all met that is wonderful. 

Have you thought about mixin universes?  Like, someone backports
internationalization to 3.7 and sets up a local SqueakMap to hold the
packages in it, while someone else creates a cryptography SqueakMap that
holds code that can't be used or redistributed by Americans.  Some
images might want to have 3.7 + m18n + cryptography, and others might
want 3.7 + cryptography, etc.  For various reasons, these mixin
repositories do seem to be useful in Debian, and so presumably they will
be useful for us too if we support it.  With the design strategy you
describe, maybe this could be supported by having multiple parent
pointers?





> I agree, one design I have somewhere in the back of my head goes like
> this:

Sounds good to me, not that I know SqueakMap internals all that well....



> 	- When you "commit" your changes you simply send your full SMAccount to
> a selected server. This means you make your modifications (creating
> releases, whatever) in your own image and then using a simple HTTP post
> or whatever, you smack your full account up on the server.

So an account is the unit of interchange between servers.  Well, I have
no idea if that will work.  If it does, terrific!  Does this include
support for the same account posting packages to a private server?  You
don't want to upload the local packages to the public server, but you
may want to reuse the account.  Alternatively, it may be reasonable to
make people have different accounts on different servers.

Incidentally, I organized Universes so that HTTP is used for retrieving
copies of the universe, but a maintained TCP connection is used for
editing.  This way, it opens the door to negotiations, as Craig would
say, between the editing image and the server.

But if HTTP POST's are enough, you don't need that.  I prefered to avoid
having to constrain the protocol that way.


> Anyway, something like the above seems pretty doable.

Cool!

> > Being disconnected does change the design problems in one way: unique
> > identifiers can no longer be guaranteed.  One general strategy for
> > approaching this, is that if the local guy defines an identifier
> > identical to what the global server has, then the local guy is
> > *overriding* the global server -- just like with class inheritance.
> 
> Well, I think the model don't need that - all SMObjects have UUIDs, but
> sure, there are a few ways to "clash" today, for example - package name
> is verified to be unique. I was thinking that any such conflicts should
> be noticed at "commit time" and if there is a conflict we simply abort
> and tell the user.

Clashes seem like a fine strategies as well.  Notice that they also seem
to happen whenever you do an "update" from a more public server; changes
that have been committed locally, may turn out to clash with something
that happened upstream.  Going the clashes route, it seems like the
model now needs to have support for "stuff killed off by an update from
upstream", plus some way for the local users to fix up the situation.

I guess another general approach, is to try and rename the UUID's
locally, in order to undo the conflict.  I don't know if this is doable
or not.

And (heck) a fourth, is that you change from UUID's to server-unique
ID's.  So when you refer to an ID, you have to know which server it
pertains to.


-Lex