On 14 April 2014 23:21, Chris Muller asqueaker@gmail.com wrote:
"Migration" means we'd have two catalogs. One with migrated stuff, the other with unmigrated stuff. So, when one goes looking for MorphicWrappers they would need to first check the "new-SqueakMap" to see if it had been migrated and, if not, go and look at the "old" SqueakMap. The whole purpose of a single, uniform, accepted Catalog is to avoid this kind of confusion.
That is not what migration means. Migration means replacing the existing thing with a new thing, with a short transition period so you know the new one's good, _and destroying the old one_.
The entire legacy SM domain model is currently up to 722k (up from 700k more than 3 years ago). It's an elegant domain model that resides entirely in memory and doesn't need changed at all to replace the server implementation. Part of the model refers to a place in a directory structure on the SM server for the .st or .sar files. So there's nothing to "migrate". We just need to replace the server implementation and keep this same domain model and storage directory structure. Sure, it they can be "refined" on a whim but that's not necessary to replace the server.
I tried to add a feature (it's from two years ago, and I can't be bothered to trawl the list to find out the details - perhaps it was so you could publish to multiple Squeak versions from within the in-image client?) to SM that required understanding the client/server protocol. I gave up after a handful of hours because I couldn't reverse engineer the protocol.
Some people want to have a new, empty SqueakMap so we can keep track of what's "new and shiny" apart from what's "old and dusty". That's understandable and SM already delineates new from old, what's been uploaded recently, what works for new versions of Squeak's and what for old versions.
Some people are clearly silly. SM tags everything, so if you want "new, shiny" you just use a new tag.
frank
On Mon, Apr 14, 2014 at 3:22 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 14 April 2014 20:46, Chris Muller asqueaker@gmail.com wrote:
... 3. I'm interested in hearing what you have to say about the design of a new SMServer, even if you're hysterical about. But I would appreciate it if you would allow me to respond in my own time.
As you may know, I put a lot of time and thought and work into SqueakMap. The goal has always been for the community to have one single source for information about all or most Squeak-based software, to the extent that, anyone who wants published software to be noticed by Squeaker's will want it to be "in Squeak's app store" too.
When you first said replace the server, I thought you meant replace the implementation and look-and-feel of the web-UI per your discretion. That would be great. Not only would the community end up with a new SM server running on 4.5/Cog, it'd also be a signature-example of a web-app to learn from that has browse, search, user-accounts and a callout API.
Then when I saw your revamp of the requirements and that something about the "closet" and, remembering past events, I wondered while I was reading it whether all my work had already gone "poof". Had to check. Whew! Downloaded a backup of entire SqueakMap.
We don't have to be friends to do good for the SqueakMap server (though it would be preferable, of course). I've had this on my own to-do list to replace because I want to learn web and it's a good example-app. I don't think it'll be a "quick-and-done" at all, because all the requirements serve a needed purpose and integrate into a overall process. If you're willing to retain "SqueakMap" as we know it today, with the domain model and all the critical functionality intact, I'd welcome that.
I think it's safe to say that the _purpose_ of SqueakMap is well-understood, and hopefully everyone knows that it's (a) underutilised and (b) very, very important. (Datum: Pharo are re-inventing/have re-invented the concept.) But having said that, if someone came along and wrote a new server that provided the same functionality as SM, and provided some means of letting people migrate with a minimum of fuss between the old service and the new, I'm sure that noone would complain. In fact, the opposite: I think that several people would be very happy at seeing some revitalisation of SqueakMap. Especially if the client/server protocol was well-documented.
frank