[Pharo-dev] Catalog loading in Spotter

Guillermo Polito guillermopolito at gmail.com
Mon Feb 20 04:27:58 EST 2017


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 at openinworld.com> wrote:

> On Mon, Feb 20, 2017 at 4:05 AM, Torsten Bergmann <astares at 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.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170220/f601e298/attachment.html>


More information about the Pharo-dev mailing list