<div dir="ltr">So let me give a PM perspective, which is generally non-technical (but, given that this is a technical topic, it is semi-technical).<div> </div><div>I see at least 4 extensibility points, in no particular order:</div><div> </div><div><ol><li>The "client". We have good separation of concerns and, therefore, build our UX on top of a set of APIs. (And do not beat me up on API vs ABI vs SPI vs. whatever -- use whatever term makes you the most comfortable.) We have made an opinionated decision to focus on a 100% cloud-native UX. However, given the availability of the API, someone could create a totally different, purposeful client UX -- for example, maybe a tight, GUI integration of Work Item Tracking in Eclipse, to make it easy to see work to be done, associate commits against Tasks, etc.</li><li>The "Major Areas" of functionality. Per the wireframes, we are working towards an opinionated bi-level UX for the top-level functionality. Essentially, each major area of functionality lives on a tab in the UX, with some name (e.g. Work, Code, Test, etc.), and offers up a short list of choices which appear just below the tab. (e.g. Code/Codebases and Code/Workspaces). Under that list is essentially a large panel, in which that major area of functionality can do whatever it wants in terms of UX. This gives is unified UX navigation but otherwise lets the extension do what it wants (within whatever limitations are a result of the UX framework/Patternfly). In my mental model, these major areas of functionality are plug-ins/extensions, resting on a common backplane. And the ones that appear really should be a run-time, per-user decision. This enables some interesting/important scenarios:</li><ol><li>As a user, I may be part of a beta test for a new top-level piece of functionality. So, when I log in, an extra tab "Foo" appears that most others do not see.</li><li>We establish a marketplace, and individual users and/or orgs elect to have new major areas of functionality enabled. These users see new major tab "Bar" when they log in.</li><ol><li>That is not an attempt to make a statement about WHERE that functionality executes (e.g. on our server), so do not assume I've implied anything about that.</li></ol><li>Almighty becomes an even broader platform for substantially more differentiated 'development' use cases via a UX drive by entitlement.</li><ol><li>For example, maybe a user has the 'citizen developer' entitlement, such that when then log into Almighty, they get a significantly simplified UX -- maybe with only just a single tab -- enabling them to solve the finds of problems of interest to them (e.g. integration solutions) -- all the while, behind the scenes, the full Almighty infrastructure and project model is being transparently used on their behalf. They can then have a 'real developer' join their project and, when that 'real developer' signs in, they see the full Almighty UX and can augment the integration solution with code, etc.</li></ol></ol><li>The "Minor Areas" of functionality. There should be a standard way for the Major Areas of functionality to express to the backplane their own extensibility points. E.g, the Work tab containing the Planner might say to the backplane 'hey, I've got a context menu exposed on work items" (e.g., when the user sees a work item, they can right-click and pop-up a menu for that work item). This would permit a 'minor extension' -- e.g., someone might write a plug-in which can graphically draw the full interconnected graph of a work item linked to other work items. And this extension would then say "hey, I'd like to add 'Visualize' as a menu choice to all of the work item context menus, no matter which major functionality area has one."</li><li>Hooked Services. You standard web hooking stuff, but in this case using Almighty as the event source. e.g., "any time a work item changes, call this remote URL with the details of the change."</li></ol><div>Okay, so where does the stuff run? Clearly, executing other people's stuff on our server is, in general, a Very Bad Idea. Still, there are two viable operating models: (1) the extension executes 'elsewhere' but has the ability to draw its UX within Almighty. (2) the extension is essentially 100% browser-based (HTML5/JS/CSS3), rendered directly in the browser and making use of APIs to get the data it needs. I've got a ton I could say on how these 2 modes could actually work -- too much for an email, tho. [FWIW, it's a proven model.]</div></div><div> </div><div>Obviously, extensions we write and/or trust could execute on our servers. I think the proper mental model is that all extensions are running 'elsewhere', but the server operator can choose to have that 'elsewhere' be the same infrastructure.</div><div> </div><div>Some pictures are probably going to help a lot...</div></div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Nov 2, 2016 at 9:22 AM, Max Rydahl Andersen <<a href="mailto:manderse@redhat.com" target="_blank">manderse@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2 Nov 2016, at 14:15, Michael Kleinhenz wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi all, preliminary notice: I can live with any of the solutions, I see advantages and problems with both. Maybe I have done too much sales on such stuff, but I think the "Consumer Model" will be a major roadblock in actually convincing people to support us. This model will require lots of effort, changes to their live system and/or deployment and operations(!) to support integrating with us. In my experience especially the last one, operations, is a real blocker for 3rd parties. Just my 0.02€ on real world adoption of products in the corporate world.. </blockquote> I'm really confused how something that requires no changes on their external systems is a problem for adoption ? I'm missing something in this argument ;) <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I think our way of approaching that question is way to technical and not enough sales. (I am feeling dirty that I have said that :-) But anyway, again: if we decide for the consumer style model, thats fine for me, I just want to say that there might be another, non-tech, view on that. </blockquote> /max <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"> -- Michael On Tue, Nov 1, 2016 at 6:30 PM, Andrew Lee Rubinger <<a href="mailto:alr@redhat.com" target="_blank">alr@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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. To me, the most important issues this thread has vetted are: 1) Encouraging extension of Almighty through new providers 2) Security 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. 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. 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. 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. S, ALR On Mon, Oct 31, 2016 at 10:57 AM, Tomas Nozicka <<a href="mailto:tnozicka@redhat.com" target="_blank">tnozicka@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Pete, (see inline) On Thu, 2016-10-27 at 13:15 -0400, Pete Muir wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This reminded me of the VS Code/LSP architecture. In this architecture there are a number of proceses running: 1) The VS Code tool 2) A server which can control and talk to any LSP implementation via a socket or REST or other transport protocol 3) The LSP implementation(s) written in the language of choice, talking a JSON protocol </blockquote> I like the separation and implementation language independence. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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). </blockquote> I am not opposing the idea, but would you mind laying out some story why it would be useful? >From my point of view vendors can run such service on OpenShift Online or any other server (or cloud). Even we were (are) planing to run OSBP on different server using HTTPS. I don't see the use case for supporting sockets (or similar mechanisms) especially when Almighty will be running in the cloud; if such mechanism could even work there. <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I don't think allowing people to write scripts that execute inside our processes is a good idea. </blockquote> +1 Regards, Tomas </blockquote> -- Red Hat Developer Group Architecture @ALRubinger </blockquote> -- Michael Kleinhenz Principal Software Engineer Red Hat Deutschland GmbH Werner-von-Siemens-Ring 14 85630 Grasbrunn Germany RED HAT | TRIED. TESTED. TRUSTED. Red Hat GmbH, <a href="http://www.de.redhat.com" rel="noreferrer" target="_blank">www.de.redhat.com</a>, Registered seat: Grasbrunn, Commercial register: Amtsgericht München, HRB 153243, Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill </div></div> _______________________________________________ almighty-public mailing list <a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/almighty-public</a> </blockquote> /max <a href="http://about.me/maxandersen" rel="noreferrer" target="_blank">http://about.me/maxandersen</a><div class="HOEnZb"><div class="h5"> _______________________________________________ almighty-public mailing list <a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/almighty-public</a> </div></div></blockquote></div> </div>