<rekado>yesterday I wanted to add some progress monitoring to PiGx and looked into what snakemake has to offer there.
<rekado>I’m not too happy with what I found, and I wonder how GWL could improve on it.
<rekado>snakemake can send its output in structured form to an API endpoint, but it will hang (and crash the workflow) when the API endpoint disappears
<rekado>it also pushes *everything* to that endpoint; all output, debug level as well as progress info.
<rekado>it doesn’t provide enough information to the API to allow the service to identify the workflow that reports on progress.
<rekado>I was thinking that the lo-fi approach might be better suited to this problem: let the workflow itself produce a status JSON blob that describes the full workflow and the current status of each step
<rekado>a monitoring server can then ask the workflow about the current status
<PurpleSym>Urgh, another RStudio quirks: If you want to run it behind a reverse proxy, it will only respect the Forwarded header, if you run it somewhere else than /. And the official documentation straight out raises the white flag and recommends using proxy_rewrite.
<PurpleSym>But it is always be respected when deciding to set cookies to HTTPS-only.
<rekado>I feel this very strong urge to … write a different Rstudio, using R like ESS does.
<rekado>I really want to like RStudio; it clearly satisfies an itch that a lot of R users feel. But whenever I look at the implementation I can’t help but feel overwhelmed. I keep asking myself if all this complexity was a conscious choice, or if it was merely a consequence of the selected starting conditions.
<PurpleSym>Bad choices (dlopen+exec R), old codebase (GWT), overwhelmed by own success (1k open issues), at the same time trying to satisfy commercial customers, lots of R ecosystem side-projects… :/
<PurpleSym>They also effectively maintain two versions of RStudio, Open Source and “Pro”.