-
Notifications
You must be signed in to change notification settings - Fork 66
Revise to use Management API for ML8+ #598
Comments
I like this idea and I'd love to help out. One concern I have is if ML9's management API will support all of it's new features out of the box. I would like to see an option supported to force bootstrap with either management API or setup.xqy in case there are bugs with the new approach. Any thoughts on how we'd implement ml capture? It seems messy to me to rely on Ruby to reconfigure the API output into ml-config format. Perhaps we bake it's existing code into a REST extension that Roxy would reach out to? Or perhaps we consider revising the ml-config format to more easily stitch the XML together? Could we also use this an opportunity to support a JSON serialization of ml-config ? |
I'm interested. It mostly needs a starting point. I do think that if we don't intend to leverage existing code, we should build a proper Ruby wrapper lib for that Manage REST api.. We should also take into consideration what we wanna do with rollback functionality, for instance.. |
Re Rob: you can already provide multiple ml-configs. And capture should produce something, that is as close to directly consumeable by Roxy as feasible, whatever format that is.. |
Regarding rollback, we could use the Packaging API for any features supported by that -- I'd expect that to cover any bootstrap functionality, though I haven't verified that. (install / rollback) Regarding a Ruby wrapper, I think @paxtonhare's MarkMapper only covers the Client API, but perhaps would be a good base to build from. (Paxton?) |
We've talked in the past about using the REST/Management API for bootstrapping instead of the Admin API, but prior to MarkLogic 7 not enough features were supported. At this point, I think anything Roxy does can be done through the Management API. I think that making this shift makes sense in order to keep up.
I propose an incremental approach, rather than trying to do it all at once (which would be too much for any of us to take on at any given time). We'd also have to hang onto the current setup.xqy code for backward compatibility with MarkLogic 6 (end-of-life June 2016) and MarkLogic 7. I expect we could hang onto the current ml-config.xml format, which means projects could continue with significant changes.
If we agree on this as a goal, then all new features could be implemented using the Management API.
Comments from all are welcome.
The text was updated successfully, but these errors were encountered: