Sebastian wrote:
>One should discuss if it might be useful and easy to implement to have a configuration browser
>that includes descriptions for the offered configurations.
I guess I'm knowledgable enough to answer this:
a) it is useful
b) if it is easy depends on where you get the description info from
c) Do not dicusss, stop lamenting and help coding :)
When I wrote the config browser there was no central way to find out which packages/configs are
working for which Pharo version. The easiest thing that could possibly work was to create
a MetaRepoForPharoXXX repo for each version XXX of Pharo and copy the working configs
into it.
The tool just queries the list of available file names and displays them.
For the initial step this was enough and still good enough that the tool opens
quick enough.
If you would LOAD ALL the configs in such a meta repo BEFORE OPENING into the
Pharo image to extract more informations (like descriptions or dependencies)
the config browser would be unusable due to bad performance of such operations.
This could be solved by caching, but so far there was no time.
Additionally as it makes sense to store such descriptions with the config Stef implemented
Catalog. Some ConfigurationOfYYY classes have such meta data for Catalog and the
project currently produces an HTML report:
https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/One must know about this. Not ideal - but a step forward to at least make it
visible somehow.
Several options:
================
1. Implement a solution to load all the config in the meta repo into the image,
extract the data the first time and write this info to a cache. Update the
cache on request. It MUST be cached, otherwise it will burn CPU cycles.
Although this cache can be shared between Pharo image with the same version
I think this is not ideal.
2. Using Stefs "Catalog" project one could (beside the HTML report) provide
something that is easy to parse from the tool so we can load the contents
of the displayed list from the web quickly When the CI runs often it
should be up to date always - but we must make sure such a job is never broken.
Would be a better option - but also needs someone to do that.
3. In the long term:
Implement a better online mechanism to register Pharo related stuff. Some kind of
PharoStore where you can register and share Packages but also other things like
tutorials, articles, video, wallpapers, ...
Then the client can query for this info (maybe using Spotter) and just load.
Feel free to shape/code on improving this.
There is something in the pipe for 3. from my side already, but only slowly progressing
maybe too much work for one person. If you want to help and know Pharo and Seaside
very well then contact me offline.
Locked
