<div dir="ltr">This reminded me of the VS Code/LSP architecture. In this architecture there are a number of proceses running:<div><br></div><div>1) The VS Code tool</div><div>2) A server which can control and talk to any LSP implementation via a socket or REST or other transport protocol</div><div>3) The LSP implementation(s) written in the language of choice, talking a JSON protocol</div><div><br></div><div>This is closest to the the Consumer model that Michael describes, but I think we could also look at also being able to run the plugin (and the thing it connects to) on our servers, but using transports other than HTTP (e.g. sockets).</div><div><br></div><div>I don't think allowing people to write scripts that execute inside our processes is a good idea.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 27 October 2016 at 12:54, Michael Kleinhenz <span dir="ltr"><<a href="mailto:kleinhenz@redhat.com" target="_blank">kleinhenz@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That may also be something Todd should look at..<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Oct 27, 2016 at 6:53 PM, Michael Kleinhenz <<a href="mailto:kleinhenz@redhat.com">kleinhenz@redhat.com</a>> wrote:<br>
> Just for addition: I am believing the Deployment-SPI is the way to go,<br>
> not because of technical considerations, just because of the market<br>
> acceptance that the system will need. to succeed. It should be as easy<br>
> as possible for vendors to integrate with us.<br>
><br>
> On Thu, Oct 27, 2016 at 6:16 PM, Tomas Nozicka <<a href="mailto:tnozicka@redhat.com">tnozicka@redhat.com</a>> wrote:<br>
>> Hi Michael,<br>
>><br>
>> (inline)<br>
>><br>
>> tl;dr; "Consumer-SPI"<br>
>><br>
>> On Thu, 2016-10-27 at 17:44 +0200, Michael Kleinhenz wrote:<br>
>>> Hi Tomas, Andy,<br>
>>><br>
>>> I encountered a foundational architectural question while thinking<br>
>>> about specific TODOs for the build stuff: is our SPI a<br>
>>> "Deployment-SPI" or a "Consumer-SPI"? Let me elaborate:<br>
>>><br>
>>> Deployment-SPI: a 3rd party build provider writes a "plugin",<br>
>>> possibly<br>
>>> something scripted that could run in a sandbox, that is deployed on<br>
>>> Almighty. The plugin provides an API defined by us for the build<br>
>>> system. The plugin itself uses the build providers proprietary<br>
>>> network<br>
>>> protocol to talk to the actual build provider's systems.<br>
>>><br>
>>> Consumer-SPI: we define a REST api that the build provider has to<br>
>>> implement. The Almighty system just gets the URL of the endpoint plus<br>
>>> the AuthN info.<br>
>>><br>
>>> Advantages Deployment-SPI:<br>
>>> * the build provider "plugin" can be written by a 3rd party different<br>
>>> from the actual build provider.<br>
>> That's true for REST SPI as well.<br>
>><br>
>>> * the build provider can be "generic" for a software, not a vendor; a<br>
>>> jenkins plugin can be used against any jenkins installation.<br>
>>> * the change requirements for the build provider on his exposed<br>
>>> services are not necessary; providing support for Almighty is just<br>
>>> writing a bit of software that is deployed elsewhere (this may be<br>
>>> cucial for adoption)<br>
>>><br>
>>> Disadvantages Deployment -SPI:<br>
>>> * we need to run software on our systems that are not under our<br>
>>> control; this needs contract-based policies with the build provider<br>
>>> and/or a well working sandbox.<br>
>> And this forces user to write in language selected by us and and a<br>
>> subset of it restricted by our environment with special functions. It<br>
>> has a steep learning curve.<br>
>><br>
>>><br>
>>> Advantages Consumer-SPI:<br>
>>> * we don't need do deploy anything on our servers, we just use the<br>
>>> remote service.<br>
>>   * user can choose implementation language and use regular constructs<br>
>> there<br>
>>   * no steep learning curve<br>
>>   * independently scalable, ...<br>
>>   * can be a proxy to build system or the system itself with exposed<br>
>> Build provider SPI<br>
>>   * no need for special technologies like sandbox<br>
>>><br>
>>> Disadvantages Consumer-SPI:<br>
>>> * the build provider must change/extend its service offering, what<br>
>>> may<br>
>>> need some investment.<br>
>> I don't think he need to change anything. He or anybody else will just<br>
>> write proxy for it fulfilling Build Provider SPI. He has to do the same<br>
>> work in case of "plugin".<br>
>><br>
>> (For example we will be writing OSBP but no change or action is<br>
>> required from OpenShift for it. It will "just translate" calls and<br>
>> objects into different ones that OpenShift understands.)<br>
>><br>
>>> Any thoughts?<br>
>> In both cases user has to at least write some kind of proxy translating<br>
>>     Build SPI into the target system. Whether it is done like a<br>
>> sandboxed plugin or fulfilled by REST SPI service.<br>
>><br>
>> I firmly believe that REST service is a better and cleaner solution.<br>
>><br>
>> So, "Consumer-SPI".<br>
>><br>
>> But let's wait for other feedback, at least from Andy.<br>
>><br>
>> Regards,<br>
>> Tomas<br>
>><br>
>>><br>
>>> -- Michael<br>
>>><br>
><br>
><br>
><br>
> --<br>
> Michael Kleinhenz<br>
> Principal Software Engineer<br>
><br>
> Red Hat Deutschland GmbH<br>
> Werner-von-Siemens-Ring 14<br>
> 85630 Grasbrunn<br>
> Germany<br>
><br>
> RED HAT | TRIED. TESTED. TRUSTED.<br>
> Red Hat GmbH, <a href="http://www.de.redhat.com" rel="noreferrer" target="_blank">www.de.redhat.com</a>,<br>
> Registered seat: Grasbrunn, Commercial register: Amtsgericht München,<br>
> HRB 153243,<br>
> Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,<br>
> Michael O'Neill<br>
<br>
<br>
<br>
--<br>
Michael Kleinhenz<br>
Principal Software Engineer<br>
<br>
Red Hat Deutschland GmbH<br>
Werner-von-Siemens-Ring 14<br>
85630 Grasbrunn<br>
Germany<br>
<br>
RED HAT | TRIED. TESTED. TRUSTED.<br>
Red Hat GmbH, <a href="http://www.de.redhat.com" rel="noreferrer" target="_blank">www.de.redhat.com</a>,<br>
Registered seat: Grasbrunn, Commercial register: Amtsgericht München,<br>
HRB 153243,<br>
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,<br>
Michael O'Neill<br>
<br>
______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/almighty-<wbr>public</a><br>
</div></div></blockquote></div><br></div>