<html><body><p><font size="2">I'd like to get some feed back on draft...</font><br><br><font size="2">It should not be any surprise that we are trying to implement a web user interface and Redfish. I think requiring every implementation of OpenBMC to now support a webui and Redfish goes against the basic principals of the project. A better approach would be to allow the machine configuration to determine what features/apps to support. The OpenBMC core would provide the infrastructure to reverse(?) proxy incoming requests to the various applications based on the application defining which routes it can handle. With those thoughts in mind, the current design needs to be tweaked slightly.</font><br><br><font size="2">FROM:</font><br><font size="2" face="Courier New">| server | app (dbus) |</font><br><font size="2">TO:</font><br><font size="2" face="Courier New">| server | reverse | app (dbus) |</font><br><font size="2" face="Courier New">| | proxy | app (web) |</font><br><font size="2" face="Courier New">| | | app (redfish) |</font><br><font size="2" face="Courier New">| | | app (...) |</font><br><font size="2" face="Courier New">Route handler added at service startup to create the proxy environment</font><br><font size="2">(figure 1: In todays design the single app defines all routes at compile time. Adding routes to that single app forces all OpenBMC machines to pick up the new routes which is undesirable) </font><br><br><font size="2">Note: due to legacy decisions the '/' and '/xyz' route are owned by the dbus app. (Could the dbus route be helpful here? All browsers use 'text/html' and our rest uses 'application/json', perhaps a nudge/redirect the user to the correct uri) </font><br><br><br><font size="2">Security:</font><br><font size="2">~~~~~~~~</font><br><font size="2">None at the proxy level</font><br><br><br><font size="2">Registering Routes:</font><br><font size="2">~~~~~~~~~~~~~~~</font><br><font size="2">Route registration will happen at service start up. An application configuration file placed in to a predetermined location will be parsed by the proxy code</font><br><br><br><font size="2">Application Requirements:</font><br><font size="2">~~~~~~~~~~~~~~~~~~~~~~</font><br><font size="2">1) The cfg file will be based on a common xxx format</font><br><font size="2">- likely need a decision as to proxy or reverse proxy before declaring config format type </font><br><br><font size="2">2) Create a bb file in the appropriate layer. Keep in mind the </font><a href="https://github.com/openbmc/openbmc"><u><font color="#0000FF">openbmc</font></u></a>/<a href="https://github.com/openbmc/openbmc/tree/master/meta-phosphor"><u><font color="#0000FF">meta-phosphor</font></u></a>/<a href="https://github.com/openbmc/openbmc/tree/master/meta-phosphor/common"><u><font color="#0000FF">common</font></u></a>/<a href="https://github.com/openbmc/openbmc/tree/master/meta-phosphor/common/recipes-phosphor"><u><font color="#0000FF">recipes-phosphor</font></u></a>/<b>interfaces</b>/<font size="2"> is for core functionality only. </font><br><font size="2">i.e. PROVIDES = 'phosphor-webui'</font><br><font size="2"> <example of how to copy the apps config file to the correct route registration location></font><br><font size="2"> </font><br><font size="2">3) Declare in the appropriate machine conf file the bb file which contains your application </font><br><font size="2">i.e. </font>OBMC_MACHINE_FEATURES<font size="2"> += 'phosphor-webui'</font><br><br><br><br><font size="2"><br>Chris Austen<br>POWER Systems Enablement Manager <br>(512) 286-5184 (T/L: 363-5184)</font><BR>
</body></html>