<div dir="ltr"><div>Hi Devs,</div><div><br></div><div>Some background:</div><div><br></div><div>Some may recall my Redis demo at the last EG conference.  In the session, I proposed deprecating the OpenSRF router.  The discussion continued, particularly with Mike R. and Galen, where we discussed retaining support for multi-domain routing for high availability setups.  (Think restarting a service on one domain/brick and having requests to said service get routed to another domain/brick via the Router).</div><div><br></div><div>Skip ahead, I've started working on code to implement multi-domain support in my Redis branch, but quickly found the existing opensrf_core.xml file to be less than ideal with respect to defining which services run on which domains, among other things.</div><div><br></div><div>Maybe this is an opportunity to change the configuration file format?  As an experiment I put together a sample of what made sense to me:<br></div><div><br></div><div><a href="https://github.com/berick/OpenSRF/blob/user/berick/lpxxx-redisrf-streams-v3/examples/opensrf.yml.example">https://github.com/berick/OpenSRF/blob/user/berick/lpxxx-redisrf-streams-v3/examples/opensrf.yml.example</a><br></div><div><br></div><div>[I used YAML because I find it tidy and flexible.  I'm more concerned about the configuration structure than the file type, so we could continue using XML or something else, but for my part YAML is superior.]</div><div><br></div><div>One key difference is that the message bus / connection section is separated into reusable chunks:</div><div><br></div><div>1. Routable domains</div><div>2. Message bus credentials</div><div>3. Connection types.</div><div>  -- These link credentials with logging configs.</div><div><br></div><div>At runtime, clients/services link a domain with a connection type to derive the bus connection information.</div><div><br></div><div>Other benefits of the modified structure:</div><div><br></div><div>* Services are collected into named groups and linked to domains instead of routers.</div><div>* Support for other named configuration chunks.  E.g. create a named database setup that can be referenced from the cstore, storage, reporter-store, etc. configurations.  Less duplication.<br></div><div>* One file format for standalone OpenSRF clients, gateways, and services.  The file just contains less stuff for clients that don't need the full data set -- or not, either works.</div><div>* Custom connection types for ad-hoc scripts, etc. so they don't require their own config file.</div><div><br></div><div>And last but not least, the changes work much better for my Redis branch, where we have to be more explicit with our bus domains and their behavior for multi-domain support.</div><div><br></div><div>One thing not included in the sample are host-specific setups, where a "brick" contains multiple hosts, some running different services than others.  This could be added, but I wasn't sure if that was still a common use case.</div><div><br></div><div>Thoughts?  Other config wishlist items?</div><div><br></div><div>Thanks for reading!</div><div><br></div><div>-b</div><div><br></div><div><br></div></div>