Crypto package loading?

> Am 25.10.2012 um 13:24 schrieb Levente Uzonyi:
>
>> On Thu, 25 Oct 2012, Tobias Pape wrote:
>>
>>> Dear all,
>>>
>>> what is the currently preferred way to load
>>> Cryptography into 4.3 or trunk?
>>
>> Load Cryptography-mtf.36 from squeaksource.com/Cryptography.
>
> ok. who could put this into the Extending the system workspace?

> On 25 October 2012 12:38, Tobias Pape <[hidden email]> wrote:
>> Am 25.10.2012 um 13:24 schrieb Levente Uzonyi:
>>
>>> On Thu, 25 Oct 2012, Tobias Pape wrote:
>>>
>>>
>>> Load Cryptography-mtf.36 from squeaksource.com/Cryptography.
>>
>> ok. who could put this into the Extending the system workspace?
>
> Would you mind providing some copy? I'm preparing the ReleaseBuilder
> at the moment, so I can add the text.
>

> On 26 October 2012 19:48, Chris Muller <[hidden email]> wrote:
> >> ok. who could put this into the Extending the system workspace?
> >
> > Guys, do we agree that, until we have a replacement, SqueakMap should
> > be the "App Store" for Squeak?
> >
> > Extending the System workspace is going away.  No one should be doing
> > any work there other than removing it.
>
> It's a chunk of text telling people how to load things. While I agree
> that SqueakMap ought to be the place to go, it isn't right at the
> moment. However, I'd be happy to regard that (pushing SM, getting it
> properly on track etc) as being a core part of 4.5.

>
> >>>> On a side note, what is the status of Crypto going
> >>>> into trunk?
> >
> > Since so many types of apps do not need any cryptography, I think it
> > should remain a separately loadable package.
>
> Agreed. Strip more stuff out the image, and make it much easier to
> load packages.
>
> frank

> SqueakMap is not something to be done some time in the indefinite future.
> It has been around a long time, and we just need to *use* it.
>
> If a package is important enough to put on SqueakMap, then just do it. It
> won't get any easier by waiting until Squeak 4.5. And if it is not important
> enough to be worth the trouble of listing it on SqueakMap, then it's probably
> not very important and there would be little point in putting it into the
> extending the system workspace or adding it to the image.
>
> Chris is giving good advice here. If the rest of us make an effort to help
> out by registering important packages on SqueakMap it will help all of us,
> and nobody will need to worry about lobbying to get their favorite package
> included in the image.
>
> Dave
>

> On Fri, Oct 26, 2012 at 11:28:09PM +0100, Frank Shearar wrote:
>> On 26 October 2012 19:48, Chris Muller <[hidden email]> wrote:
>> >> ok. who could put this into the Extending the system workspace?
>> >
>> > Guys, do we agree that, until we have a replacement, SqueakMap should
>> > be the "App Store" for Squeak?
>> >
>> > Extending the System workspace is going away.  No one should be doing
>> > any work there other than removing it.
>>
>> It's a chunk of text telling people how to load things. While I agree
>> that SqueakMap ought to be the place to go, it isn't right at the
>> moment. However, I'd be happy to regard that (pushing SM, getting it
>> properly on track etc) as being a core part of 4.5.
>
> SqueakMap is not something to be done some time in the indefinite future.
> It has been around a long time, and we just need to *use* it.
>
> If a package is important enough to put on SqueakMap, then just do it. It
> won't get any easier by waiting until Squeak 4.5. And if it is not important
> enough to be worth the trouble of listing it on SqueakMap, then it's probably
> not very important and there would be little point in putting it into the
> extending the system workspace or adding it to the image.
>
> Chris is giving good advice here. If the rest of us make an effort to help
> out by registering important packages on SqueakMap it will help all of us,
> and nobody will need to worry about lobbying to get their favorite package
> included in the image.
>
> Dave
>
>>
>> >>>> On a side note, what is the status of Crypto going
>> >>>> into trunk?
>> >
>> > Since so many types of apps do not need any cryptography, I think it
>> > should remain a separately loadable package.
>>
>> Agreed. Strip more stuff out the image, and make it much easier to
>> load packages.
>>
>> frank
>

> On Fri, Oct 26, 2012 at 11:28:09PM +0100, Frank Shearar wrote:
>> On 26 October 2012 19:48, Chris Muller <[hidden email]> wrote:
>> >> ok. who could put this into the Extending the system workspace?
>> >
>> > Guys, do we agree that, until we have a replacement, SqueakMap should
>> > be the "App Store" for Squeak?
>> >
>> > Extending the System workspace is going away.  No one should be doing
>> > any work there other than removing it.
>>
>> It's a chunk of text telling people how to load things. While I agree
>> that SqueakMap ought to be the place to go, it isn't right at the
>> moment. However, I'd be happy to regard that (pushing SM, getting it
>> properly on track etc) as being a core part of 4.5.
>
> SqueakMap is not something to be done some time in the indefinite future.
> It has been around a long time, and we just need to *use* it.
>
> If a package is important enough to put on SqueakMap, then just do it. It
> won't get any easier by waiting until Squeak 4.5.

> Dave
>
>>
>> >>>> On a side note, what is the status of Crypto going
>> >>>> into trunk?
>> >
>> > Since so many types of apps do not need any cryptography, I think it
>> > should remain a separately loadable package.
>>
>> Agreed. Strip more stuff out the image, and make it much easier to
>> load packages.
>>
>> frank
>

> On 27 October 2012 00:10, David T. Lewis <[hidden email]> wrote:
>> On Fri, Oct 26, 2012 at 11:28:09PM +0100, Frank Shearar wrote:
>>> On 26 October 2012 19:48, Chris Muller <[hidden email]> wrote:
>>>>> ok. who could put this into the Extending the system workspace?
>>>>
>>>> Guys, do we agree that, until we have a replacement, SqueakMap should
>>>> be the "App Store" for Squeak?
>>>>
>>>> Extending the System workspace is going away.  No one should be doing
>>>> any work there other than removing it.
>>>
>>> It's a chunk of text telling people how to load things. While I agree
>>> that SqueakMap ought to be the place to go, it isn't right at the
>>> moment. However, I'd be happy to regard that (pushing SM, getting it
>>> properly on track etc) as being a core part of 4.5.
>>
>> SqueakMap is not something to be done some time in the indefinite future.
>> It has been around a long time, and we just need to *use* it.
>>
>> If a package is important enough to put on SqueakMap, then just do it. It
>> won't get any easier by waiting until Squeak 4.5.
>
> My point in mentioning 4.5 is that we're (_I'm_) currently behind on
> the 4.4 release, and I don't want to see effort diverted to things
> that cause further delay. It would be much more helpful for the
> community to beat the MC tests into being clean, for instance.
>
>> And if it is not important
>> enough to be worth the trouble of listing it on SqueakMap, then it's probably
>> not very important and there would be little point in putting it into the
>> extending the system workspace or adding it to the image.
>>
>> Chris is giving good advice here. If the rest of us make an effort to help
>> out by registering important packages on SqueakMap it will help all of us,
>> and nobody will need to worry about lobbying to get their favorite package
>> included in the image.
>
> "Putting it into extending the system workspace" is about maybe 5
> seconds of effort. At any rate, I need to concentrate on the 4.4
> release, but if someone wants to SM-ify Crypto, then why not add "get
> it at SM by evaluating this" to the workspace?
>
> I certainly didn't mean to suggest leaving SM to languish. I'd be very
> happy to have it, because our current infrastructure ("our" includes
> Pharo) is extremely fragile and heavily depends on quite a few single
> points of failure (squeaksource.com, ss3.gemstone.com, ...). SM ought
> to help with that (as long as it itself is highly available).

>
> frank
>
>> Dave
>>
>>>
>>>>>>> On a side note, what is the status of Crypto going
>>>>>>> into trunk?
>>>>
>>>> Since so many types of apps do not need any cryptography, I think it
>>>> should remain a separately loadable package.
>>>
>>> Agreed. Strip more stuff out the image, and make it much easier to
>>> load packages.
>>>
>>> frank
>>
>
>

> On Sat, 27 Oct 2012, Frank Shearar wrote:
>
>> On 27 October 2012 00:10, David T. Lewis <[hidden email]> wrote:
>>>
>>> On Fri, Oct 26, 2012 at 11:28:09PM +0100, Frank Shearar wrote:
>>>>
>>>> On 26 October 2012 19:48, Chris Muller <[hidden email]> wrote:
>>>>>>
>>>>>> ok. who could put this into the Extending the system workspace?
>>>>>
>>>>>
>>>>> Guys, do we agree that, until we have a replacement, SqueakMap should
>>>>> be the "App Store" for Squeak?
>>>>>
>>>>> Extending the System workspace is going away.  No one should be doing
>>>>> any work there other than removing it.
>>>>
>>>>
>>>> It's a chunk of text telling people how to load things. While I agree
>>>> that SqueakMap ought to be the place to go, it isn't right at the
>>>> moment. However, I'd be happy to regard that (pushing SM, getting it
>>>> properly on track etc) as being a core part of 4.5.
>>>
>>>
>>> SqueakMap is not something to be done some time in the indefinite future.
>>> It has been around a long time, and we just need to *use* it.
>>>
>>> If a package is important enough to put on SqueakMap, then just do it. It
>>> won't get any easier by waiting until Squeak 4.5.
>>
>>
>> My point in mentioning 4.5 is that we're (_I'm_) currently behind on
>> the 4.4 release, and I don't want to see effort diverted to things
>> that cause further delay. It would be much more helpful for the
>> community to beat the MC tests into being clean, for instance.
>>
>>> And if it is not important
>>> enough to be worth the trouble of listing it on SqueakMap, then it's
>>> probably
>>> not very important and there would be little point in putting it into the
>>> extending the system workspace or adding it to the image.
>>>
>>> Chris is giving good advice here. If the rest of us make an effort to
>>> help
>>> out by registering important packages on SqueakMap it will help all of
>>> us,
>>> and nobody will need to worry about lobbying to get their favorite
>>> package
>>> included in the image.
>>
>>
>> "Putting it into extending the system workspace" is about maybe 5
>> seconds of effort. At any rate, I need to concentrate on the 4.4
>> release, but if someone wants to SM-ify Crypto, then why not add "get
>> it at SM by evaluating this" to the workspace?
>>
>> I certainly didn't mean to suggest leaving SM to languish. I'd be very
>> happy to have it, because our current infrastructure ("our" includes
>> Pharo) is extremely fragile and heavily depends on quite a few single
>> points of failure (squeaksource.com, ss3.gemstone.com, ...). SM ought
>> to help with that (as long as it itself is highly available).
>
>
> SqueakMap is intended to be used as a catalog of load scripts (just like the
> "Extending the system" workspace). Those scripts still depend on external
> sites.

> Levente
>
>
>>
>> frank
>>
>>> Dave
>>>
>>>>
>>>>>>>> On a side note, what is the status of Crypto going
>>>>>>>> into trunk?
>>>>>
>>>>>
>>>>> Since so many types of apps do not need any cryptography, I think it
>>>>> should remain a separately loadable package.
>>>>
>>>>
>>>> Agreed. Strip more stuff out the image, and make it much easier to
>>>> load packages.
>>>>
>>>> frank
>>>
>>>
>>
>>
>

>> On SqueakMap, FWIW, I'd recommend these changes:
>>
>> 1. When it moves to the new server, discontinue the web access. Make it GUI
>> access only. Updating the SqueakMap server as seen at map.squeak.org is
>> endless, tedious, and superfluous.
> We still need the web interface to do other things like creating new
> Packages and maintaining Categories, among a few more use-cases.  We
> cannot get rid of it yet, but the server is some of the most difficult
> code to maintain -- so I'd be all for the notion of a complete
> replacement using Altitude or any other web-framework.  Someone was
> working on that at one point (Green-Neon).  ;)  Given Squeak's web
> capability, it seems like it would not be that hard given that the SM
> domain model is small and fairly simple (and could even stand to be
> simplified a bit more).
>
>> 3. Remove "SqueakMap Categories" from the "open..." menu because it's
>> redundant.
> +1
>
>> Replace it with "Create SqueakMap Release" so it's easy to find
>> Chris M.'s GUI app.
> I think creating a Release is an operation that can only happen in the
> context of a selected Package, so it may not be a simple matter to put
> that on the open... menu.
>
>> 4. Encourage people to load scripts into the "Create New Release" GUI app,
>> so applications, not packages, are installed with a single click.
>>
>> http://wiki.squeak.org:8080/squeak/6182
> Yes, and to Frank's concern about HA, recall that SM has always worked
> by downloading a copy of its domain model to the local machine.
>
> There is no doubt that SqueakMap domain, server and UI need to be
> simplified and/or replaced, but until someone can step up to do it,
> what we have now at least works for a crude App Store.
>
> Thanks.
>

> On 2012-10-27 1:25 PM, Chris Muller wrote:
>>>
>>> On SqueakMap, FWIW, I'd recommend these changes:
>>>
>>> 1. When it moves to the new server, discontinue the web access. Make it
>>> GUI
>>> access only. Updating the SqueakMap server as seen at map.squeak.org is
>>> endless, tedious, and superfluous.
>>
>> We still need the web interface to do other things like creating new
>> Packages and maintaining Categories, among a few more use-cases.  We
>> cannot get rid of it yet, but the server is some of the most difficult
>> code to maintain -- so I'd be all for the notion of a complete
>> replacement using Altitude or any other web-framework.  Someone was
>> working on that at one point (Green-Neon).  ;)  Given Squeak's web
>> capability, it seems like it would not be that hard given that the SM
>> domain model is small and fairly simple (and could even stand to be
>> simplified a bit more).
>>
>>> 3. Remove "SqueakMap Categories" from the "open..." menu because it's
>>> redundant.
>>
>> +1
>>
>>> Replace it with "Create SqueakMap Release" so it's easy to find
>>> Chris M.'s GUI app.
>>
>> I think creating a Release is an operation that can only happen in the
>> context of a selected Package, so it may not be a simple matter to put
>> that on the open... menu.
>>
>>> 4. Encourage people to load scripts into the "Create New Release" GUI
>>> app,
>>> so applications, not packages, are installed with a single click.
>>>
>>> http://wiki.squeak.org:8080/squeak/6182
>>
>> Yes, and to Frank's concern about HA, recall that SM has always worked
>> by downloading a copy of its domain model to the local machine.
>>
>> There is no doubt that SqueakMap domain, server and UI need to be
>> simplified and/or replaced, but until someone can step up to do it,
>> what we have now at least works for a crude App Store.
>>
>> Thanks.
>>
> I think there needs to be a server for SqueakMap, but I don't think that
> server should have a public interface.
>
> SqueakMap shouldn't have releases, only a single Installer script per
> application. The package and release distinctions need to be put aside.
> There shouldn't be one package with lots of releases. If people want to
> explore releases or versions, they can go to SqS or SqS3. Part of the
> confusion is that package names are also the names of the applications.
> SqueakMap should be about applications, not packages or releases. And for
> each application, there should be only one Installer script. There should be
> no categories publicly changeable by users. Only administrators. You have a
> GUI for downloading something from SqueakMap and a GUI, a reworked version
> of Chris M.'s new release GUI, to add an application to the map or to change
> an existing Installer script. SM should list, add and execute Installer
> scripts.
>
> That's it. The taxonomy and nomenclature here needs to change from category,
> package, and release to application and script. SM today does too many
> things.  A new SM should do one thing - download applications. If people
> want to move beyond that simplicity, then can read the installer script
> readily visible and pursue the constituent packages spread into releases
> available at a public repository like SqS or SqS3.
>
> Chris
>