component: dynamic configuration

[Pierre-Yves Ritschard]

Hi,

I've been using an approximation of what component provides in my
applications for quite a while, and I'm trying to see if it's feasible
to move to component, in the sake of homogeneity with the rest of the
clojure world and to see if there are things that make my life easier.

I have a couple of apps which expose a somewhat generic way of
manipulating data in a certain way. Most follow the pattern of having
several possible inputs (which must all adhere to a protocol), an engine
that does its work and several possible outputs (again, adhering to a
protocol).

While configuring each of these inputs or outputs as components is
straightforward, I failed to find a good strategy for storing them and
constructing the system-map correctly.

Did anyone tackle this yet and if so are they willing to share their
approach ?

Cheers,
- pyr

[Stuart Sierra]

Not sure if this helps, but remember that components and systems are just records, and records behave like maps. You can construct an empty `system-map` and then `assoc` components or even `merge` other maps into it.

–S

[Jeroen van Dijk]

This could be a nice example of how to use component in practise: https://github.com/bevuta/pepa

Internally we configure the system map differently. This is based on yet another library https://github.com/RedBrainLabs/system-graph We have extended the idea of this library and we now have a file based system configuration where subsystems (graphs/maps) can be merged.

HTH

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pierre-Yves Ritschard]

Hi,

I did get this far indeed. My general question was rather: what's your
general approach ?

Say I happen to have a config that loosely looks like:

{:inputs [{:type :inputA ...} {:type :inputB ...}]
:engine {:engine-opt1 :engine-arg1}
:outputs [{:type :outputA ...} {:type :outputB ...}]}

Would you directly assoc :inputA :inputB :outputA :outputB components
in the first layer of the system map or would you retain a hierarchical
structure and if so, are there any downsides to this ?

Cheers,
- pyr

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure+u...@googlegroups.com

> <mailto:clojure+u...@googlegroups.com>.

[Stuart Sierra]

Hi pyr,

There are many downsides to hierarchical structure of components and systems. The effects are complicated and hard to understand. See, for example, the discussion at
https://groups.google.com/forum/#!topic/clojure/2-baBp61XTs/discussion

I recommend that system maps be kept "flat," without any nested systems.

To prevent name clashes, you can always generate unique keys for the components.

–S

[Pierre-Yves Ritschard]

Thanks for the clarifications!