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