[Box-Admins] Re: SqueakSource

[Tobias Pape]

Am 26.08.2013 um 21:59 schrieb Chris Muller <ma.chris.m at gmail.com>:

>> 
>>> As Dave mentioned, the immediate priority is simply ensuring continued
>> operation of squeaksource.com.  He is heading up the transition to a new
>> server this week whether that's box3, box4 (Gandi) or a server hosted by
>> Robert's group.  If we cannot get it running on a new image and/or VM
>> immediately, we'll just have to deal with the crashes/lockups until we can.
>>> 
>>> While I think Squeak should host its own services, unfortunately what we
>> have right now is unacceptably dangerous.  It appears someone has hacked
>> our SqueakSource implementation to bypass its original design for
>> persistence to use "image-based" persistence.  Image-based persistence, in
>> itself, would be fine, except for the fact that our Linux-based SS system
>> scripts carelessly KILL the SS process by PID as a means of opening the
>> image under VNC -- potentially when the image could be in a half-saved
>> state!
>> 
>> Which SqS are you referring to? Fabrizio once send Andreas and Me a (then
>> current) image of the squeaksource.com (SS.C) and
>> IIRC, it just had VNC running, so you probably are referring to
>> source.squeak.org (S.S.O)?
> 
>  Sorry, I also do not understand what you mean by the original design
>> being “hacked” for image-based persistence.
>> 
> 
> Yes, I was referring to SSO, which is running a slightly newer/forked
> version of SqueakSource and using the save-the-image persistence.

What do you exactly mean by save-the-image-persistence? I ask, as I carefully
hand-merged/back-ported/cross-ported features from SSO _and_ SSC to SS3 prior
to its alpha release.

> SSO is also running on an old version of Squeak and old VM.  Whatever is
> good for the SS upgrade will be good for SSO and vice-versa.
> 
>> Such a misfortune could wipe out the entire community if we were unable
>> to recover from a backup.  Therefore, I fully support your idea to move to
>> SqueakSource3 running on GemStone.
>>> 
>>> But there is one more option.  Last month, Tim Rowledge expressed
>> interest in having a more-capable SqueakSource that could support what
>> Magma-based MC repositories provide today:
>>> 
>>> 
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-July/172243.html
>>> 
>>> The advantage to this approach, besides having a working server example
>> based on Squeak, is that all MCDefinitions across all Versions of each
>> SSProject would be canonicalized and indexed inside the repository, so that
>> the 'browse mc versions' and 'browse mc origin' functions which are
>> afforded by Magma-based MCRepository's would be available on the trunk
>> repository for everyone.
>> 
>> I had the Idea (but not yet enough pressure) to provide similar features
>> for SS3.
>> 
> 
> McModel is self-contained.  Besides substituting an RcDictionary for the
> MagmaPreallocatedDictionary, you might be able to lift it straight from
> Magma.  It's indexing is sufficient to provide the minimum MCRepository
> subclass-responsibility API, plus the aforementioned (#historyOf:
> aMCDefinition) and (#originOf: aMCDefinition) functions, all without MC
> even knowing it exists.

I will have a look, thanks for sharing.

> 
> 
>>> I've already begun the work for this, but if there is no interest in
>> this, I will simply bow out and support the idea that we go with the
>> GemStone solution.
>> 
>> SS3 already cracks open MCZs for determining diffs, browsing code, finding
>> parents, reading
>> version informations. It would be easy to just cache this information and
>> provide links inbetween.
>>  Remember, however, that both, a Magma-Based solution or a SS3-feature
>> would have to respect
>> acls in the sense, that you shouldn't be able to browse into a
>> non-readable project by means of
>> 'browse mc origin'.
>> 
> 
> Yes, I'd planned for each SSProject to have its own McModel instance, so
> access is allowed only through the existing Project level ACL.

sure, but do only acl-accessible versions get added to the McModel instance
or every 'reachable' ancestor?

> 
> We have ODBMS' we should use them to exceed what we had before with only
> the filesystem.

:)
Best
	-Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/box-admins/attachments/20130826/45955476/signature.pgp