Goal: Remote enable Continuum
(from Trygve)
Currently the "remote" interface to Continuum does directly to it's core interface which gives Continuum very little room to change the way it works internally. I know that the idea of having the big Continuum interface was to have a course-grained, use case-oriented interface but it doesn't give the room we need to be able to evolve Continuum.
The Continuum interface is an excellent way to making it easy to interface with Continuum internally if you're extending it "from within" (as opposed to changing a workflow). I feel that the internal extension points mainly should be a set of interfaces that we define, like the ContinuumNotifier and the ContinuumBuildExecutor interfaces. These are the interfaces that should remain as is forever.
So I propose:
- A new "RemoteContinuum" interface which we give it's own life cycle independent of the Continuum life cycle. The types that this interface should not be used internally by the core. They should be generated from a Modello descriptor.
- All the different variants of the RemoteContinuum interfaces should be implemented, but they won't ever change. Note that interface B can extend A and is what should happen in most cases. Minor changes should (must?) introduce a new sub-interface as it only adds functionality (no breaking or removing of functionality).
- This should make it easier for the clients to implement a certain interface version and know that once it's client-side is properly implemented, it won't break. Ever.
Advantages:
- Flexibility to change the Continuum internals while the tools on top of continuum (not extensions) doesn't break.
- Ability to generate all kinds of server-side implementations of the interface. At least these are the ones we (probably) want:
- SOAP: best for Java/C#/.NET clients and other integration platforms
- XML-RPC: best for PHP/PERL/Python/Ruby clients
- Java: best for in-VM extensions of Continuum. This is probably also what other high-level/on-top-of extensions of Continuum should use.
- I suggest that the socket trigger and other high-level functionality relies on the RemoteContinuum interface, as it makes it more immune to API changes