Dear Malcolm. I'm still having trouble seeing the intended flow, and I have the feeling I'm missing something.
My first question is why I would create two separate components C and A, instead of just having one component A that both installs a channel in the system map and starts a thread for pushing updates to it when the external resource changes? More importantly, it's not clear to me what should happen with the updates that are sent over the channel. To make things concrete let's say the resource is a configuration file specifying how to access an external database (url, login and credentials, ...). In order to access the database, I create a database component D providing public functions (fetch-data ...) and (store-data ...) etc. These functions need access to an up-to-date db-spec or connection, which in turn depends on the config values sent over the configuration update channel. Now I see three possibilities: 1) Component D subscribes to the config update channel and keeps a private state containing an up-to-date db-spec which in turn is accessed by the public fetch and store functions I don't think this is the way to go because I thought the whole purpose was to keep all state in a single place (i.e. "system")? This brings me to possibility 2: 2) Component D, upon receiving a config update, updates the system global var root, and the fetch and store functions in turn access the global system to get an up-to-date db-spec I thought this was the way to go, but I'm confused since the system is defined in the user namespace which is not supposed to exist in production? 3) Component D does not subscribe to the config update channel. Instead components that want to access the database should themselves subscribe to the config update channel and provide the store and fetch functions with an up-to-date db-spec. But then I feel that this simply pushes the problem one level up and that the db component does sufficiently encapsulate all the internals of accessing the database and maintaining an up-to-date connection etc.? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
