richgroot
commented
7 years ago Nick,
I considered switching DCM from SOMA to REST but held off for two reasons. First, DP's REST interface doesn't provide, at least at the moment, any new functional capabilities beyond those provided by SOMA. For example, REST import config is identical in capabilities to SOMA import config. Second, export files are still XML rather than JSON (has that changed and I didn't notice?) and since part of what DCM does is rewrite exports, that seemed like a reason to stick with XML for the moment. REST and JSON is clearly an improvement from a new developer's perspective, especially if one isn't skilled in XSLT, but the cost of rebuilding a bunch of working code in a new language simply to avoid XSLT has to be carefully considered. (I defer to no one in my zeal for rewriting, um, refactoring!)
It would be pretty simple to build a new plugin that simply exposed DP's REST interface, which would give you immediate access to the domain-* and save operations that are mentioned in the list. The other operations in that list all end in "-from-def", which is where DCM adds value by allowing a user to specify environment-specific variations in a convenient form. Would a new plugin continue to use existing XML file formats, or would a new set of JSON formats need to be invented? Rewriting the existing XSLT into JS wouldn't generally be too difficult, though it would take a good deal of time and effort. It might be quicker to simply pick up skills with XSLT, though. ;-) In any event, what is proposed is certainly feasible, though a good deal of work.
I suspect, though, that the problem isn't really the difficulty of extending the plugin. I suspect that the greater problem that users are working against is the difficulty of generating the .dcm.xml and .zip files, and using them in UCD steps. Plus we need some higher level steps, and better file upload capabilities. (I will never understand why DP Engineering didn't add an SFTP server exposing the DP file system years ago.)
If I've assessed the situation correctly, it may be more useful to keep the existing project as is and begin a new project to build the UI that DCM (and DataPower) has always needed. DataPower has a gap when it comes to being able to specify what you want deployed, how, and where. DCM is a command-line oriented effort to address that gap, and it is useful as far as it goes. Rewriting large chunks of DCM in JavaScript will take a good deal of time and effort and ultimately will leave the DP/UCD user in the same place - trying to configure a set of deployments using "bear skins and stone knives." - Spock
As an interesting aside, both REST and SOMA encapsulate the API that the DP web UI itself relies upon via AJAX. The down side of that is that there are generally a lot more UI-level operations than you would need for doing deployments, and some operations that would be convenient for deployments are missing. The up side is that both REST and SOMA are well-suited to building the sort of UI that I've been thinking about.
A proper UI would integrate with live DP appliances, saved DP exports, and DCM files, providing a clean experience in preparing for deployments, and it would be based on current Node/HTML5/CSS/JS technology that many people would have the skills to contribute to. Such a UI could read/write files that could then be integrated easily into UCD configurations.
Either path is going to be considerable work. Rebuilding the bottom layer in REST+JS moves the developer experience forward, with the hope that it will enable the user experience to move forward. Building a new UI doesn't do anything to ease the developer's burden, but it may move the user experience much further forward. I'd be a lot more inclined to spend my own time on the new UI and attendant DCM improvements. There's one vote! ;-)
Hope this helps, and I'll be interested to see what the community thinks. (And people criticized me for writing excessively long and information-packed emails! See, I can be brief!)
Thanks, Rich
On Mon, Jun 12, 2017 at 1:48 PM, Nick Mathison notifications@github.com wrote:
Issue discussing the potential of migrating the SOMA calls to REST calls. This change would increase the ability to debug and contribute to the DataPower plugin.
This change could come in the form of a new plugin or update to this one. The plugin wrapping Ant calls wrapping SOMA calls provides a high level of complexity when debugging and modifying. Separating these REST calls into a new plugin would drastically simply the entire plugin.
As stated by the wiki documentation, the most popular commands are:
- domain-create
- domain-quiesce
- domain-unquiesce
- idcred-from-def
- import-dpo or import-from-def
- load-balancer-group-from-def
- save
- upload-from-def
- valcred-from-def These commands should likely be tackled first.
@tonyffrench https://github.com/tonyffrench indicated that the SOMA calls access several XSLTs that would need to be accounted for. This issue is meant to discuss the feasibility of this change.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ibm-datapower/datapower-configuration-manager/issues/53, or mute the thread https://github.com/notifications/unsubscribe-auth/ADuMmt-yH5Z3Cx93GZKsTWghYx5IYpzWks5sDXoIgaJpZM4N3c3S .
Issue discussing the potential of migrating the SOMA calls to REST calls. This change would increase the ability to debug and contribute to the DataPower plugin.
This change could come in the form of a new plugin or update to this one. The plugin wrapping Ant calls wrapping SOMA calls provides a high level of complexity when debugging and modifying. Separating these REST calls into a new plugin would drastically simply the entire plugin.
As stated by the wiki documentation, the most popular commands are:
@tonyffrench indicated that the SOMA calls access several XSLTs that would need to be accounted for. This issue is meant to discuss the feasibility of this change.