GateKeeper Dependencies - NCIOCPL/cgov-digital-platform GitHub Wiki
CDR Publishing has a number of dependencies on GateKeeper which in turn depend on the Percussion CMS. This document only concerns the points where the Percussion CMS is a factor. Anything which is directly persisted to the database (e.g. the various dictionaries) is assumed to continue unaltered for the initial release.
- MP3 files *
- Cancer Info Summaries
- Drug Info Summaries
- CDR Publish Preview
* MP3 file processing is intertwined with image processing as both are sent to GateKeeper as "Media" documents.
This is very similar to image files. For now, GateKeeper can continue to handle all media files, we'll just need to update the render/save logic to write to the file system, similarly to how images are written. (But with audio going a different path.)
The same discussion points apply to both of these.
The dueling approaches are
- Alter the CDR publish process to not contact GateKeeper for these document types.
- Continue to send the data and modify GateKeeper to throw it away.
Change the CDR
Altering the CDR to not contact GateKeeper for these document types involves modifying the subsystem which handles those communications. This subsystem needs to remain in place until GateKeeper is eventually retired, at which point the subsystem can be excised en masse.
Specific challenges include:
- Tracking which documents were sent to GateKeeper.
- Handling dependency groups where some documents are sent and some aren't (e.g. Dictionary term and pronunciation).
Change GateKeeper
Similarly, changing GateKeeper also requires changes to a system which will needs to continue running. This also gets complicated if the results of sending to GateKeeper vs. Drupal are different.
Specific challenges include:
- Changing the reporting to always report success.
- Reconciling bookkeeping when GateKeeper succeeds and Drupal fails (or the other way around).
Render in the CDR with the same XSL Transforms as are used for sending the content to Drupal. The Drupal system only needs to be responsible for supplying a basic "C-clamp" with the necessary CSS and JavaScript. The CDR already knows the correct versions of any required media files and can include the correct references in the rendering without requiring any post-processing.
This needs more details, but it would be good to do the rendering and then embed the result in the same "C-clamp" as mentioned above. Possibly change from returning a full-blown page to just returning the rendered result, ready to be injected into the C-clamp by the calling system.