[squeak-dev] Plugin Repository Needed [was FFI callbacks]

Chris Muller ma.chris.m at gmail.com
Sat Sep 5 23:47:42 UTC 2015


>> On Sat, Sep 5, 2015 at 2:19 AM, H. Hirzel <hannes.hirzel at gmail.com> wrote:
>>> I mean to use the function of SqueakMap being a catalogue which
>>> references artefacts available elsewhere.
>>
>> Yep, binaries are no problem for SqueakMap, it was designed to solve
>> exactly this problem -- the cataloging of any software, in any format,
>> hosted at any location.
>>
>>> For dealing with binaries additional provision has to be made to deal with it.
>>
>> No additional provisions need to be made, except possibly adding a
>> "Plugin" category.
>
> I'm unsure. Its external things, nothing that is in image.

The image knows where the VM is installed.  With SqueakMap you could
browse all entries in the new "Plugin" Category, and simply
right-click "Install" any of them straight into the system on the
spot, without ever leaving the image.  SqueakMap automatically backs
things up in its local cache, so there'd be a copy there too..

> In my humble option, the 'execute anything' approach of SqueakMap has
> its appeal, but I don't think its sustainable.

Actually, sustainability and avoiding bit-rot were major core
requirements [1] of the 2011 effort, and, in fact, having a catalog of
pure Smalltalk snippets organized and hierarchically tagged, is of the
aspects that has contributed to its sustainability.  If you are going
to say something is unsustainable, please say why..

> I'd like to keep existing stuff
> there,

Right, and that's why "existing stuff" remains still accessible to
this day, and thru tommorrow, because it this approach _is_
sustainable.  If it weren't, they wouldn't be..

> but I'd refrain from putting new projects there, or only if SqueakMap
> would support Metacello natively.

I really don't understand why you feel threatened by SqueakMap -- or
why you feel it is a substitute or alternative to Metacello.  It's
just documentation for goodness' sake.  Is it okay with you if some of
us document some project locations to help newbies and ourselves?

What about that new user just last week?  He wanted to install Seaside
into Squeak 5.  Now, if seaside.st or squeak.org/projects would just
refer users exclusively to SqueakMap for installation, then he would
have been playing with Seaside in under 5 minutes because, guess what,
Seaside 3.1.1 installs flawlessly into Squeak 5 from SqueakMap right
now.

Unfortunately, seaside.st and squeak.org/projects decides instead to
provide the little snippets of code for installation right there on
the web-page (hard-coded?  how is that for sustainable?) which,
surprise surprise, *don't work*.  Another user, left high-and-dry.
Cases like his bother me, and are what caused me to expend all that
effort in 2011 to solve this issue.  If there's something wrong with
it, could you help me fix it instead of tearing it down?

I think most people like Squeak to have an "App Store", and want their
projects to be visible there, that's why we are already up to 23
packages in there for 5.0.  If making SqueakMap support Metacello
natively would win your support, it would make me very happy.  It
already supports about 5 or 10 other formats natively, why not?

 - Chris

[1] -- http://wiki.squeak.org/squeak/6183


More information about the Squeak-dev mailing list