"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.

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.

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.

On Mon, Apr 14, 2014 at 3:22 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 14 April 2014 20:46, Chris Muller <asqueaker at 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
>