As far as I remember, the main problem was not bandwidth but a blocking and non-responsive UI.

Imagine I'm in the university, or in a company with a proxy. And I forget to set the proxy. Then, while spotter tries to fetch catalog entries, it would block the image and throw a timeout error some minutes after.

So, maybe for the future and besides Ben's C option (which I like) I have a

D) Load catalog entries in background in a non-blocking way

�� - and while catalog entries are not yet available, they should not be shown

Even further, It would make sense a solution that mixes Ben's caching with background loading of the catalog entries... ��

Guille

On Mon, Feb 20, 2017 at 1:03 AM, Ben Coman <btc@openinworld.com> wrote:

On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <astares@gmx.de> wrote:
> In the past in Pharo it was possible to open Spotter, type in the name of a framework/project to load
> from catalog, perform a search and just hit ENTER to easily install the project.
>
> This was following the Spotter idea that it is easy to access most informations of Pharo
> with the Spotter tool.
>
> There always was and still is a setting in "Settings" -> "Catalog" -> "Display catalog projects in Spotter".
> This setting is ENABLED BY DEFAULT but could be switched off in the settings tool or custom preference
> scripts if this is problematic for someone.
>
>
> Now in Pharo 6 there is an additional class "GTSpotterExtensionSettings" to activate/deactivate
> Spotter extensions. While nearly all of the Spotter extensions are enabled the one for the catalog
> integration is DISABLED BY DEFAULT.
>
> This leads to several effects:
>
>�� ��1. While in the past it was possible in a fresh Pharo image to search and install out of
>�� �� �� the box it is (as of today in the not yet released Pharo 6) not possible anymore to quickly
>�� �� �� start by searching and installing from catalog using Spotter.
>
>�� ��2. It is very confusing that in the settings "Display catalog projects in Spotter" is enabled but a search
>�� �� �� in Spotter gives no results. Most people will not not know about the second setting and easily
>�� �� �� get lost and think this behavior is just broken.
>�� �� �� Also this second setting for the Spotter extension is much more hidden between all the other
>�� �� �� Spotter extension enablements very and hard to find.

Generally its not good to have two settings for the one thing.

>
>�� ��3. Several of my youtube videos demonstrating Goodies like DesktopManager, QuickAccess,
>�� �� �� MessageFlowBrowser, ... directly start by loading the tools from Spotter. Anyone newbee who will
>�� �� �� follow these will not only be confused - but also stuck in trying Pharo when he learns
>�� �� �� from these videos.

UI things do evolve and videos date.�� But these seem worthwhile to keep current.

>
>�� �� �� I was asked several times on Slack and via Mail from people who were not able to reproduce ... this
>�� �� �� is really annyoing. Especially this gives the wrong impression to newbees. Things should be easy
>�� �� �� not complicated.
>
> To my knowledge disabling the Spotter search in Pharo 6 came up due to some Pharo teaching in regions
> with slow internet connection.

This made sense at the time.�� It is a worse first impression if UI
lags when this central part of the UI is interfaced.
How often would it access the network?�� Every time? Or did it cache
the result for a day, etc?

> I understand that we would like to support these Pharo users too as best
> as possible in their out of the box experience ... but (without being able to prove) I think that 90% or
> more Pharo users have a regular internet connection. Otherwise it would be hard to work with updates,
> project loading, PharoLauncher, STHub or Iceberg/GitHub.
>
> Also my own personal experience is that even on low bandwidth network this Catalog Spotter search for
> me was always fast enough (as I often use Pharo in trains with slow connections or on a Pi with slow
> connections and less processing power). I do not know about all others from the community.
>
> I invested hours in the past in developing and introducing the initial configuration browser to Pharo,
> later improved and helped shaping its replacement CatalogBrowser, also contributed this spotter search
> for the catalog items so things are more accessible, easy and enjoyable. That's why I also invested
> hours in udpating configs or pushing you to put things into catalog.
>
> Because accessibility is key. Only when things are easy to access and understandable people will
> enjoy Pharo.
>
> Currently in an out-of the box image this easy access to the projects via Spotter is blocked.
> Additionally I have to explain to anyone who asks me that there is a second non-obvious/more hidden setting
> leaving an unpleasant feeling how many others unknown to me will struggle with this issue.
>
> I see two solutions:
>
>�� �� A) We enable both settings by DEFAULT to bring back the Spotter search and installation
>�� �� �� ��of catalog items - with the clear benefit of having
>�� �� �� �� �� - the previous behavior in Pharo back
>�� �� �� �� �� - the out of the box ability to search for catalog projects in any fresh image
>�� �� �� �� �� - no confusion among the user base anymore regarding the settings
>�� �� �� �� �� - we have unbroken Youtube videos that newbees can continue to follow
>�� �� �� �� �� - if a user asks (like often) how to get Seaside, Artefact, Mongo, Teapot or other projects we can
>�� �� �� �� �� �� just tell him "search in Spotter and you should be fine" as most of them have a config in
>�� �� �� �� �� �� the catalog.
>
>�� �� �� �� �� �� Remember that not all of us know about all the github pages or nice Metacello expressions.
>�� �� �� �� �� �� So the easier things are found and accessible the better it is.
>
>�� �� B) If A is still a "No go" for the community we should at a minimum switch the defaults of
>�� �� �� ��the two settings:
>
>�� �� �� �� => we ENABLE the Spotter extension (GTSpotterExtensionSettings perform: #GTSpotter_spotterCatalogProjectsFor: with: true)
>�� �� �� �� => we DISABLE the catalog setting (CatalogSettings displayCatalogProjectsInSpotter: false)
>
>�� �� �� ��With this at least we have no confusion among the user base anymore regarding the settings.

C)�� Could a STON file of the catalog be cached in the zip of
Image/Changes files?
That zip might be updated daily to keep it current.
Then in a fresh image Spotter searches the cached file for a instant response,
while the Catalog is updated from the network in the background.

Even with fast Internet the Catalog should only need to auto-update once a day,
with results cached in a common file to be accessed when fresh images
are started.

The Spotter UI might display the last update date as part of the
Catalog sub-heading in its results.

cheers -ben

>
> I would clearly and strongly vote for option A as my preferred one.
>
> I agree there are regions/continents with very low bandwidth - but Pharo will rival with state of the art
> technologies where loading/installation megabytes from the web is often not seen as an issue. There are
> many package registries out there (from debian packages) up to Maven, npm in JS, ... or look at Docker.
> Shuffling megabytes around is a reality in todays technologies.
>
> So to be honest I never understood this whole "bandwidth" discussion and even if this comes up it could
> be solved with a note in the download/welcome screen or pointing to a custom preference script for low bandwidth
> situations.
>
> Sorry for having to bring this up again ... but I would like this to be solved BEFORE Pharo 6 will
> be pushed out of the door. Keeping it like it is without further actions would be really stupid.
>
> Thanks for you comments, ideas or votes.
>
> Thanks
> T.
>