[orion-dev] Alternative ways to build on Orion.

[John J Barton <johnjbarton@xxxxxxxxxxxxxxx>]

I understand from Simon that Cross-Origin Resource Sharing (CORS, http://www.w3.org/TR/cors/) support may not be practical. So here I am thinking out loud about why I thought I needed such a thing and possible alternatives.

I will frame my discussion around extending Orion because that is the way I think about it.  

Orion plugins. 

  An arbitrary URL is handed to your Orion account to be loaded into an iframe. 

  The code awaits extension-point calls from Orion pages.  

  No CORS needed because the iframe can be cross-origin. 

  The communications is limited to strings passed over .postMessage(); 

  Plugin developers need a hosting site, limiting the complexity of plugins.

  

REST API clients.

  Web page operates on Orion server.

  Page has control flow.

  Page has to be on the same domain as the server or CORS support.

  Communications is JSON objects over HTTP.

  Only option (w/o CORS) is hosting in Orion.

Orion plugins using REST API.

  Plugin has to be on the same domain as server as for REST client.

I've written one of each, Nonymous, Orchard (opm), and ATopWI resp.

As far as I can figure out, without CORS the latter two options need either 

  Server-install-option, or

  Client-proxy support.

Server-install-option means a way to install plugins into the server URL namespace. This is what I am doing now in a primitive way. I create a self-hosting Site, then add URL mappings for the components of the extension. That way the Site acts like an extended Orion server. It makes for a tedious install process as Martin Lippert can testify ;-).

Client-proxy support means a plugin from the Orion site that offers the Orion server API over the Orion plugin system, plus some magic that allows one plugin to access another one.  

My plan is to create an Orion-plugin-using-REST to make the primitive Server-install-option less tedious. Any other suggestions?

Finally there is one additional issue which may be unique to me. I started out creating a conventional site with Orion, that is a tree with /lib branches bringing in other projects. I've now concluded that this model is not practical. 

Synchronizing the /lib branches is tedious, error prone, and time consuming. At first I thought git submodule support would solve the problem. But now I doubt it, the real problem here is that we are shifting to a world with lots of small projects building on each other. We need to ref projects uniformly not drop them into other projects at various random places in the source tree. 

Node, npm and system like apt-get already face up to this problem. They put the modules down in named locations independent of the use. 

git projects have a natural naming system: the git project name. By using the Site feature in Orion I can create this naming system: all of the projects live, once only, in their own git repo and this repo is mapped to project/ in the server name space.  Dependents ref the projects by their project name.  So far this has worked well for me.  Obviously this issue (and my extensive experience with json-proxy-over-postMessage from crx2app) points me towards the Server-install-option.

Any thoughts?

jjb