> On 20 Feb 2017, at 10:30, Pavel Krivanek <[email protected]> wrote: > > > > 2017-02-20 10:27 GMT+01:00 Guillermo Polito <[email protected]>: > 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 > > AFIK the main problem was that there was not possilbe to do it non-blocking > way.
Yes that is true. (It is actually DNS resolving that is blocked in some freak case). But the thing is, the problematic situation only occurs for a very small percentage of people, like less than 1%, probably even much less. (Remember, nobody can produce a repeatable case for it). So the question is, is that enough reason to act as if we are still in the 90's when internet was a luxury and cut features that depend on it ? If you have no network today, you're in big trouble anyway. (Again, if you turn off your network, no blocking will happen at all, try it). So what is more important ? The general functionality of the 99.xxx % or the unreproducible freak case ? > -- Pavel > > > 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 <[email protected]> wrote: > On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <[email protected]> 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. > > > > >
