Skip to content

Instantly share code, notes, and snippets.

@mmulich
Last active May 2, 2016 18:41
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mmulich/1a3871c9f7a1a732c875aaac97255de3 to your computer and use it in GitHub Desktop.
Save mmulich/1a3871c9f7a1a732c875aaac97255de3 to your computer and use it in GitHub Desktop.

Write up pro tools doc

Pro tools has been discussed in terms of cnxml and providing an interface on publishing to accept cnxml in a completezip type format.

How does this look from a DMS Point-of-View?

The new DMS desk tool will have a web interface where the following will be true:

  • Provide links to download the .complete.zip for any given content.
  • Provide links to download any resources associated with the content (e.g. the PDF).
  • Provide a means to upload a .complete.zip for publication, which will subsequently provide:
    • a means to view state and errors
    • a means to (optionally) preview the content as HTML before submission for publication

The DMS will download a .complete.zip of the content. They will edit/create the portions of the content that are needed. (It's implied that in order to work on the content they will unzip the file.) They will then zip up the contents of the work (a simple tool can be created to do this if necessary, but right click to 'Archive' should just work). Lastly, they will upload the edited and archived .complete.zip file to the DMS desk instance. This upload can either be done as a cli script or via the web interface.

Why provide an interface to accept cnxml on publishing?

We have cli tools to transform cnxml to html, so let's use these to compile html and send the payload as a format publishing already accepts and acknowledges (i.e. internal epub).

  1. Acquire .complete.zip (from zope|publishing)
  2. Work on content
  3. Convert .complete.zip to .internal.epub
  4. Send .internal.epub to publishing (for publication)
  5. Repeat as needed

New development is now scoped to two areas: a tool to convert a .complete.zip to .internal.epub and an interface on publishing to produce a .complete.zip

The external tool is useful in this situation because we can quite litterally chuck it in to the digital forest when we are done with it. There it can bitrot and paradise. :) Also, as a separate tool, others (beyond cnx devs) can maintain it without having contextual knowledge of other parts of the system. And another thing, this does pre-validation of cnxml before submitting it to publishing.

Let's tentatively call this new tool, DMS desk.

Can a DMS run this tool locally? Sure. Do they have to run it locally? No, I think the approach here is to treat this new tool as an editor similar to cnx-authoring. It will communicate with cnx-publishing similar to how cnx-authoring does. In which case it will utilize the same mechanisms for error handling.

The publishing interface to produce a .complete.zip file should be relatively easy. I feel confident that making this small read-only change will not affect the cnx codebase in adverse ways. Additionally, the implementation of this interface can be done in two increments; proxy zope (immediate results) and later actually build the .complete.zip.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment