<div dir="ltr">Gave some time to think this through. :)  Appreciate the thoughts Michael, because I think your email here has redirected our line of thinking into something better than originally designed.<div><br></div><div>To me, the most important issues this thread has vetted are:</div><div><br></div><div>1) Encouraging extension of Almighty through new providers</div><div>2) Security</div><div><br></div><div>Now, I had been initially conceiving something akin to what Michael is calling the "Deployment" model; an interface that providers implement.  On further reflection I've come to find the REST-based approach outlined as the "Consumer" model accomplishes all of our goals and better handles the two points above.</div><div><br></div><div>For 1), we let users register their own service, running *somewhere*, to be written in whatever language and execution environment they decide.  This imposes on providers writers the burden of deploying their thing instead of deploying it into Almighty, but, as 2) shows, this is a good thing.</div><div><br></div><div>The security constraints of 2) really say that we will absolutely not run untrusted code in our online service offering.  Initially I'd thought that anyone who wants to write their own providers could be on their own to host an Almighty instance as well, but by making the provider model a firewall where untrusted code runs externally to Almighty, we could be opening ourselves off to safe extensibility or community-driven extensions in the future.  While this is not a requirement for our first launch, it's definitely the kind of thing Todd envisions for us going forward.</div><div><br></div><div>TL;DR for me now: a REST-based extension SPI model, and registration mechanism with Almighty core which sets that up.  Will look forward to seeing those designs.</div><div><br></div><div>S,</div><div>ALR</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 31, 2016 at 10:57 AM, Tomas Nozicka <span dir="ltr"><<a href="mailto:tnozicka@redhat.com" target="_blank">tnozicka@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Pete,<br>
<br>
(see inline)<br>
<span class=""><br>
On Thu, 2016-10-27 at 13:15 -0400, Pete Muir wrote:<br>
> This reminded me of the VS Code/LSP architecture. In this<br>
> architecture there are a number of proceses running:<br>
><br>
> 1) The VS Code tool<br>
> 2) A server which can control and talk to any LSP implementation via<br>
> a socket or REST or other transport protocol<br>
> 3) The LSP implementation(s) written in the language of choice,<br>
> talking a JSON protocol<br>
</span>I like the separation and implementation language independence.<br>
<span class=""><br>
><br>
> This is closest to the the Consumer model that Michael describes, but<br>
> I think we could also look at also being able to run the plugin (and<br>
> the thing it connects to) on our servers, but using transports other<br>
> than HTTP (e.g. sockets).<br>
</span>I am not opposing the idea, but would you mind laying out some story<br>
why it would be useful?<br>
<br>
>From my point of view vendors can run such service on OpenShift Online<br>
or any other server (or cloud). <br>
<br>
Even we were (are) planing to run OSBP on different server using<br>
HTTPS. <br>
<br>
I don't see the use case for supporting sockets (or similar mechanisms)<br>
especially when Almighty will be running in the cloud; if such<br>
mechanism could even work there.<br>
<span class=""><br>
><br>
> I don't think allowing people to write scripts that execute inside<br>
> our processes is a good idea.<br>
</span>+1<br>
<br>
<br>
Regards,<br>
Tomas<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Red Hat Developer Group Architecture<div>@ALRubinger</div></div></div></div></div>
</div>