For Discussion Only: re: db access

[reedstrm]

It seems to me that the goals of DMS-Press can be met by using the existing publishing interface, with extensions to handle the interim case of needing to handle CNXML (and potentially collxml), rather than having another component talking to the production repository DB.

[mmulich]

I don't think the goals can be met using the existing publishing interface. The existing interface accepts an epub, which breaks that into models. So it's not as clear cut as one might think.

Making it a separate service serves a few purposes. Firstly, it makes the solution very disposable. When we no longer support this interface--in say a year--we throw it away. No cruft is left behind, it just simply vanishes as if it never existed. This makes it both easy for removal and QA'ing.

The other reason for the service separation is so that the service can iteratively become an authoring component over time. The idea is to make the DMS Press service a publishing component at first, which means that it will interact with the archive database directly. Over time we will parallelize the procedure to become a hybrid component of both publishing and authoring. The service will start to have a side-effect that publishs (like an authoring component, publishing via the epub format) to a QA environment. This will integrate our html transforms and publishing service in a non-intrusive way. All parties involved (DMS, textbook devs, cnx devs, etc.) will be able to inspect the results of our system prior to utilizing it in a production manner.

[mmulich]

CC @karenc @philschatz ...thought you guys might be interested in the design.

[mmulich]

I should also mention that scoping the solution to a separate service adds to its maintainability.

Furthermore, I have a feeling that this service could be used as a github webhook endpoint. We let the service validate the completezip structure, collxml and cnxml files. This means a quicker response to development, which addresses one of the DMS's major pain points. The alternative to validating via a travis job that would involve installing a bunch of software prior to actually validating, which I anticipate could take several minutes. If the webhook bit of this works as expected, any commits to a book should be validated in seconds.