On 14 April 2014 23:21, Chris Muller <asqueaker at 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 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
>>
>