Gesendet: Montag, 20. Februar 2017 um 11:27 Uhr
Von: "Sven Van Caekenberghe" <[email protected]>
An: "Pharo Development List" <[email protected]>
Betreff: Re: [Pharo-dev] Catalog loading in Spotter
> 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.
> >
>
>
>
