[orion-dev] Need help with creating an extension point

[Kris De Volder <kdvolder@xxxxxxxxxx>]

Hi all,

This corresponds to my second use case.

I'm now already going on the assumption that the "gcli console" itself won't actually be itself an orion plugin. 
Previous discussion seems to indicate this isn't possible, and also it probably isn't necesary 
if the core gcli functionality is going to be contributed back to orion.

However before it can be contributed back I need to figure out how it can be made extensible... so that contributors can define new gcli commands, types and fields.

This is necessary because only some of what I've implemented is of general use. Whereas other commands are specific to cloudfoundry support and don't belong in a 'core orion example server'. 

It would also be nice if git commands could be contributed via this mechanism rather than 'baked in' with the core console implementation.

I am hoping the orion plugin mechanism and/or service registry model *will* work for this use case. I'm hopeful because it probably is somewhat similar to the existing 'orion.page.commands' service. 

But I'm having a hard time figuring out how to make this work (with or without using the orion services/plugins model).

gcli provides three 'extension points':
  (1) adding commands: define parameters for a command and an exec function
  (2) adding types: define how to parse/unparse different types of params, 'parse' also defines how to compute completions.
  (3) adding fields: define UI for editing parameters of a given type.

In terms of difficulty to wrap these mechanisms as orion services I'd say that
  3 > 2 > 1

So let's start with just the easy case first: adding commands.

A typical command definition will look like this:

		gcli.addCommand({
			name: 'vmc login',
			description: 'Login to currently selected target',
			manual: 'Login to currently selected target',
			params: [
					    {
							name: 'email',
							type: 'string',
							description: "User's email address"
					    },
					    {
							name: 'passwd',
							type: 'string',
							description: 'Password'
						}
			],
			exec: function (...) {...}
		});

A typical exec function: (for a command that has some asynchronous execution)

function (args, context) {
    var promise = context.createPromise();
    doSomething(function (result) { //callback
        promise.resolve(render(result));
    });
    return promise;
}

The 'render' function turns the result into either a dom node or html text string.

The hard part (for me at least :-) in turning this into something like a 'service' registered 
by a plugin is the exec function. As was discussed on the orion call 2 weeks ago, 
functions can't be passed through the 'JSON.stringify' barrier.

I could imagine this 'exec' function being part of the service implementation. So the function itself
wouldn't need to pass through the JSON barrier. However, its parameters would.

The args object is (upto now) no problem. As far as I know it is usually pure data (although this may depends on the types of the parameter are and how its parse function is implemented). The context object I don't know how to deal with. It provides richer API including a 'createPromise' function that is needed to support asynch style command executions (and that's needed for my use case which executes commands via server-side http APIs).

I'm looking for three possible things from this post:
  1) suggestions on how/if something like this could work within the current orion architecture
 if the answer to 1 is that it isn't possible:
     2) starting a discussion on how to modify the architecture to make it possible 
     3) suggestions on how to make it work within the current limitations (i.e. an acceptable/reasonable way to bypass the limitations of the current architecture).

Kris