This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-12-07
Channels
- # adventofcode (269)
- # beginners (100)
- # boot (6)
- # cider (4)
- # cljsrn (4)
- # clojure (161)
- # clojure-android (31)
- # clojure-argentina (2)
- # clojure-brasil (8)
- # clojure-greece (45)
- # clojure-india (2)
- # clojure-madison (2)
- # clojure-russia (17)
- # clojure-spec (4)
- # clojure-sweden (1)
- # clojure-uk (32)
- # clojurescript (93)
- # core-logic (2)
- # cursive (21)
- # data-science (2)
- # datomic (46)
- # defnpodcast (1)
- # duct (5)
- # emacs (21)
- # events (1)
- # fulcro (17)
- # graphql (13)
- # job (1)
- # jobs (2)
- # leiningen (11)
- # lumo (3)
- # off-topic (119)
- # om (4)
- # onyx (2)
- # planck (6)
- # portkey (12)
- # re-frame (5)
- # reagent (3)
- # ring (5)
- # shadow-cljs (27)
- # spacemacs (19)
- # specter (6)
- # unrepl (9)
Re: Onyx Dashboard. We're currently debating between rolling our own tools or adding to Dashboard, but when it comes to viewing window state, either A: Dashboard needs to connect to peer group to run peer-http-query, B: Dashboard needs to connect to S3 checkpointing bucket, or C: Dashboard shouldn't connect to either of these pieces architecturally, so we should separate out that piece. Thoughts?
That’s a pretty good assessment of the situation. Pyroclast did both of those things for different reasons, but I haven’t thought a lot about whether the dashboard is the right place to put it. It’s probably a better place to put it than anywhere else, but I think I’d want to see most of the code to do so in its own lib, maybe lib-onyx?