- sounds all fine by me. I'll close the ticket as won't do.

It's not been registering on my To Do list, so honestly it's unlikely to appear soon.

I suspect part of the probem here is that we're not quite sure what we want. Someone thought "There ought to be a Z39.50 settings page", but we don't really have a sense of what needs to go in it — especially as configuration is all done via stacked config files.

So we're left with this single rather dull boolean option about whether to run the Z39.50 server at all — something easily handled in ops, just like the enabling or disabling of any other module — and little incentive to implement it. And at the same time, implementing this one tiny setting of dubious value would involve deciding where on the back-end to store that bit, which is difficult because mod-configuration seems to be deprecated and there is no other obvious module to own this information. So if we blindly implement, we might end up creating a whole new backend module mod-z3950-config just to hold literally one bit of information in the FOLIO database! And even then the devops people would need to create new code that goes off and looks at that bit somehow, to determine whether to start the server.

So honestly I think we should just close this as Won't Do. And if at some point we find there is a real requirement for a more powerful facility for configuring the Z39.50 server via a GUI, we can open a new issue that describes what's required, and have a serious discussion about what it would entail.

Hi  - do you think this work will be done during sprint-108, or would it be more correct if I moved it to the feature  Z39.50 support. Post MVP?