<div dir="ltr">Hi,<br><br>On Tue, Sep 12, 2023 at 4:24 PM Bill Erickson via Evergreen-dev <<a href="mailto:evergreen-dev@list.evergreen-ils.org">evergreen-dev@list.evergreen-ils.org</a>> wrote:<br><div>> At this point, we're still at the "should we do this?" stage, but I'm also happy to discuss </div><div>> specifics regarding potential planning and implementation.  </div><div><br></div><div>I think the moment has long passed for any thought of OpenSRF as a message broker that other projects would adopt, and I agree that a unified installation process would be helpful.</div><div><br></div><div>I do have a small qualm at losing the ability to readiy upgrade OpenSRF independently of Evergreen, and there have been times in the past when we collectively have benefited from being able to do just that. However, the current overall development velocity of the project makes that a more theoretical than actual benefit nowadays.</div><div><br></div><div>I do feel more strongly that RediSRF should come first and exist as an OpenSRF release, even if that release then gets quickly deprecated in the course of a merge of OpenSRF and Evergreen. Why? Because happily, RediSRF does look like it's on course to be readily backportable to early versions of Evergreen by anybody who cares to -- and would provide a benefit that would repay the effort.<br></div><div><br></div><div>Regards,</div><div><br></div><div>Galen<br></div>--<br>Galen Charlton<br>Implementation and IT Manager<br>Equinox Open Library Initiative<br>gmc@equinoxOLI.org<br><a href="https://www.equinoxOLI.org">https://www.equinoxOLI.org</a><br>phone: 877-OPEN-ILS (673-6457)<br>direct: 770-709-5581</div>