Hey, in some private emails we started a discussion about Front-End / Back-End split for the browser "app", toying with some of the ideas for the re-architecture.
At first it was mostly a mail to organize a meeting, then it quickly ends-up into a bit more detail and opinions about what can be done. Michael suggest that it will be better to continue the conversation on dev-fox. So here we are. Feel free to join the conversation. Vivien. Forwarded conversation Subject: BE/FE Split for Browser ------------------------ From: *Michael Henretty* <[email protected]> Date: Mon, Nov 30, 2015 at 11:17 AM To: Vivien Nicolas <[email protected]>, Tim Guan-tin Chien < [email protected]>, Benjamin Francis <[email protected]>, "Pastor, Alberto" <[email protected]>, Marcus Cavanaugh <[email protected]>, Gregor Wagner <[email protected]>, Francisco Jordano <[email protected]>, "Page, Wilson" <[email protected]>, Justin D'Arcangelo < [email protected]>, Evelyn Hung <[email protected]>, Reza Akhavan < [email protected]> Last week, Vivien reached out to me about starting the discussions for BE/FE split for the Browser. I agree this work will be important if we want to support multiple form factors going forward, which seems to be the direction Ari is taking FxOS. Ideally we would include everyone in one meeting, but due to timezone constraints I think this is impossible. So let's have a prelimary meeting this week with a Euro/Asia time slot, and then schedule a followup(s) in Mozlando. Wilson, Francisco, Vivien, it would be great if you could give us some detail about how the BE/FE split work most benefited porting Music app to the TV (it's too bad Justin can't be there too). Then I would like to discuss how/if this should be applied to the Browser. I think it's extremely important to have engineers who worked on the Browser App for the TV present. We need to know the pain points, especially if we want to merge System Browser with the TV's browser app (which is also unclear). Evelyn, can you suggest engineers who should be present for this discussion? Unless someone objects now, I am going to schedule this meeting for Wed morning Euro/Wed afternoon Asia. Thanks, Michael ---------- From: *Wilson Page* <[email protected]> Date: Mon, Nov 30, 2015 at 11:22 AM To: Michael Henretty <[email protected]> Cc: Vivien Nicolas <[email protected]>, Tim Guan-tin Chien < [email protected]>, Benjamin Francis <[email protected]>, "Pastor, Alberto" <[email protected]>, Marcus Cavanaugh <[email protected]>, Gregor Wagner <[email protected]>, Francisco Jordano <[email protected]>, Justin D'Arcangelo <[email protected]>, Evelyn Hung <[email protected]>, Reza Akhavan <[email protected]> Sounds good, thanks for setting this up Michael :) One thing that is left to decide on Music side is whether we can go ahead with FE/BE split as separate apps running in separate processes (via IAC). This is something Vivien has been playing with the last couple of weeks. Early experiments show that the BE app would likely have to be preloaded so that it's already running when dependent FE app is launched. When not already running it takes too long to boot the FE app and BE app at the same time. *W I L S O N P A G E* Front-end Developer Firefox OS (Gaia) London Office Twitter: @wilsonpage IRC: wilsonpage ---------- From: *Michael Henretty* <[email protected]> Date: Mon, Nov 30, 2015 at 11:39 AM To: Wilson Page <[email protected]> Cc: Vivien Nicolas <[email protected]>, Tim Guan-tin Chien < [email protected]>, Benjamin Francis <[email protected]>, "Pastor, Alberto" <[email protected]>, Marcus Cavanaugh <[email protected]>, Gregor Wagner <[email protected]>, Francisco Jordano <[email protected]>, Justin D'Arcangelo <[email protected]>, Evelyn Hung <[email protected]>, Reza Akhavan <[email protected]> On Mon, Nov 30, 2015 at 11:22 AM, Wilson Page <[email protected]> wrote: > One thing that is left to decide on Music side is whether we can go ahead > with FE/BE split as separate apps running in separate processes (via IAC). > This is something Vivien has been playing with the last couple of weeks. To be clear, right now the Browser in the smart phone is not its own app. Instead, the mozbrowser iframe that represents the browser "tab" is directly managed by the system on the same level as other app windows. TV on the other hand (if I am not mistaken) does have a separate Browser app that manages it's own tabs. I'm not sure if adding more apps to the recipe is what we want here, but instead less. Anyway, this is what's up for discussion. ---------- From: *Benjamin Francis* <[email protected]> Date: Mon, Nov 30, 2015 at 12:06 PM To: Michael Henretty <[email protected]> Cc: Wilson Page <[email protected]>, Vivien Nicolas <[email protected]>, Tim Guan-tin Chien <[email protected]>, "Pastor, Alberto" < [email protected]>, Marcus Cavanaugh <[email protected]>, Gregor Wagner < [email protected]>, Francisco Jordano <[email protected]>, Justin D'Arcangelo <[email protected]>, Evelyn Hung <[email protected]>, Reza Akhavan <[email protected]> Yes I'm very happy to have a discussion about this, but given that there is no browser app on smartphone I'd like to clarify exactly what it is we're discussing here. If we're talking about the search app then the good thing is that it only has two views and those two views are already split into their own separate HTML files. It's also always had a frontend/backend split between the Places database and the front end UI because the Places database logic is used by other apps too. If we're talking about creating a RESTful Places web service using Service Workers I think that's a great idea and something I've wanted to do for a while now, but I think we'd need cross-origin Service Workers (foreign fetch) support on the platform to make that possible given the back end is shared between apps. I'd actually like to see a "places.firefox.com" web service on the web, with storage in the cloud, which can be consumed and cached by multiple front ends. I'd really rather we didn't introduce any more inter-app communication using the proprietary inter-app communication protocol because that seems to be moving further away from the web, not closer to it. The other part of the "browser" is the browser chrome which is part of the system app and I'm not sure whether it makes sense or is possible to change the architecture of that without changing the architecture of the whole system app. If there's a back end for browser chrome then it's the window manager and changing the architecture of that sounds like a wider discussion. Something we do need to discuss is whether we want to add support for a TV form factor in the mainstream browser UI in Firefox OS as TV currently uses a completely separate browser app. But that's going to have to be part of a wider discussion about merging the TV system app into the mainstream one as well. Ben ---------- From: *Vivien Nicolas* <[email protected]> Date: Mon, Nov 30, 2015 at 2:37 PM To: Benjamin Francis <[email protected]> Cc: Michael Henretty <[email protected]>, Wilson Page <[email protected]>, Tim Guan-tin Chien <[email protected]>, "Pastor, Alberto" < [email protected]>, Marcus Cavanaugh <[email protected]>, Gregor Wagner < [email protected]>, Francisco Jordano <[email protected]>, Justin D'Arcangelo <[email protected]>, Evelyn Hung <[email protected]>, Reza Akhavan <[email protected]> What we are speaking of is a good question. As Mike and Ben mentioned, the 'browser' is essentialy a special window instance in the window manager. The 'window' thing is what I would like to isolate first - using regular <iframe> - yes, that's a big change to the window manager. I think the window manager and the transition manager should basically do: WindowManager.open/WindowManager.close and TransitionManager will just animate things on the screen. I know it will be a bit more complicated in practice :) But the content of the Window itself should not leak to them (by content I mean app chrome, any dialogs, lists, etc.., JS, CSS). It is similar in idea to what we have tried to achieve already by wrapping window and its UI into a root <div>, but in stricter way that isolate contexts and force window type to have one html file per behavior. My pov is that without such an encapsulation, adding new windows or altering a behavior of one of our window type / app chrome combo is always tricky. And if we are going to ride the multiple form factors world, we need to make our daily tasks easier. How is it going to help ? - Such changes will not rely on media queries for the global display / UI behavior of a window type. Media queries can still be used inside the iframe to select images based on the screen size, or make small adjustments - but not for the whole display... - Instead of hard to follow CSS/JS files that manages all possible window type and states, we would have specific CSS file for a specific UI and specific JS files for a specific behavior. I'm not saying this can not be reached without such an encapsulation, but it makes that mandatory and by default it will organize our directory structure for this part of the system app (honestly having everything in system/js is not great for newscomer) - Scope some types of regressions to a specific part of the code. Instead of global regressions for all our possible app window, some type of regressions, notably those that tries to change a specific UI, or a specific behavior will be scoped. Also since the code will be organized in a way where each type of window will have its own directory it will scope commits to a specific repository making investigation easier. Obviously not all regressions can be fixed this way, as there will likely be some shared scripts over the views, but it helps for some types of regressions. - Easy to add/remove a view. You just need to create the necessary directory and files. And you should not have to hack anything outside your directory, like the window manager. As a result, if someone wants to experiment, or customize a specific behavior it can write the code, in any way. No need to follow a specific pattern or naming conventions. For us it also means that if a partner wants to create its own type of behavior for a specific things, we know we are safe on our side as long the changes lives into this dedicated directory. People can either create dedicated githib repo to work on a specific window type if they want too... How does it help with the TV browser app ? The TV browser app is similar to our old browser app in the idea - that's really painful based on our prior experience. It force us to duplicate code, delegating system level tasks to the browser app itself :/ One of the solution we can do to merge it back to the master system app is to: #1 Have each window living into its <iframe> #2 The UI of the mentioned window can be whatever you want, it will not affect the system app. #3 The system app is the one transitioning between those windows (like today) #4 In the case of the TV, the system app can decide to display 'tabs' in order to make navigation between those windows easier. This is a system based decision, likely based on the available width on the screen. #4 is the only UI/behavorial difference between the a mobile and a tv version of browser from the system app point of view. Then merging the rest of the TV system app is an other story. It would also make it easy to write an addon that intercept a particular WindowManager.open call to rewrite the url and serve your own custom views without introducing too many risks in the system app... I know this is some work. ---------- From: *Vivien Nicolas* <[email protected]> Date: Mon, Nov 30, 2015 at 2:41 PM To: Wilson Page <[email protected]> Cc: Michael Henretty <[email protected]>, Tim Guan-tin Chien < [email protected]>, Benjamin Francis <[email protected]>, "Pastor, Alberto" <[email protected]>, Marcus Cavanaugh <[email protected]>, Gregor Wagner <[email protected]>, Francisco Jordano <[email protected]>, Justin D'Arcangelo <[email protected]>, Evelyn Hung <[email protected]>, Reza Akhavan <[email protected]> On Mon, Nov 30, 2015 at 11:22 AM, Wilson Page <[email protected]> wrote: > Sounds good, thanks for setting this up Michael :) > > One thing that is left to decide on Music side is whether we can go ahead > with FE/BE split as separate apps running in separate processes (via IAC). > This is something Vivien has been playing with the last couple of weeks. > For this specific case I think it will not match the 'Service' definition, so it won't need a separate process. That said, if we split as the right level we may be able to do some experiments with multi-process to render to the UI but our multi-process nested <mozbrowser> story is not that great so it will takes a lot of time :/ > > Early experiments show that the BE app would likely have to be preloaded > so that it's already running when dependent FE app is launched. When not > already running it takes too long to boot the FE app and BE app at the same > time. > > *W I L S O N P A G E* > > Front-end Developer > Firefox OS (Gaia) > London Office > > Twitter: @wilsonpage > IRC: wilsonpage > > On Mon, Nov 30, 2015 at 10:17 AM, Michael Henretty <[email protected]> > wrote: > >> Last week, Vivien reached out to me about starting the discussions for >> BE/FE split for the Browser. I agree this work will be important if we want >> to support multiple form factors going forward, which seems to be the >> direction Ari is taking FxOS. Ideally we would include everyone in one >> meeting, but due to timezone constraints I think this is impossible. So >> let's have a prelimary meeting this week with a Euro/Asia time slot, and >> then schedule a followup(s) in Mozlando. >> >> Wilson, Francisco, Vivien, it would be great if you could give us some >> detail about how the BE/FE split work most benefited porting Music app to >> the TV (it's too bad Justin can't be there too). Then I would like to >> discuss how/if this should be applied to the Browser. >> >> I think it's extremely important to have engineers who worked on the >> Browser App for the TV present. We need to know the pain points, especially >> if we want to merge System Browser with the TV's browser app (which is also >> unclear). Evelyn, can you suggest engineers who should be present for this >> discussion? >> >> Unless someone objects now, I am going to schedule this meeting for Wed >> morning Euro/Wed afternoon Asia. >> >> Thanks, >> Michael >> > > ---------- From: *Vivien Nicolas* <[email protected]> Date: Mon, Nov 30, 2015 at 2:54 PM To: Benjamin Francis <[email protected]> Cc: Michael Henretty <[email protected]>, Wilson Page <[email protected]>, Tim Guan-tin Chien <[email protected]>, "Pastor, Alberto" < [email protected]>, Marcus Cavanaugh <[email protected]>, Gregor Wagner < [email protected]>, Francisco Jordano <[email protected]>, Justin D'Arcangelo <[email protected]>, Evelyn Hung <[email protected]>, Reza Akhavan <[email protected]> On Mon, Nov 30, 2015 at 12:06 PM, Benjamin Francis <[email protected]> wrote: > > If we're talking about creating a RESTful Places web service using Service > Workers I think that's a great idea and something I've wanted to do for a > while now, but I think we'd need cross-origin Service Workers (foreign > fetch) support on the platform to make that possible given the back end is > shared between apps. I'd actually like to see a "places.firefox.com" web > service on the web, with storage in the cloud, which can be consumed and > cached by multiple front ends. I'd really rather we didn't introduce any > more inter-app communication using the proprietary inter-app communication > protocol because that seems to be moving further away from the web, not > closer to it. > > I think this one is an other discussion. But I will be happy to have a REST like web services for Places. I also think you should not block your minds on IAC if we use it today. IAC is going to die as soon foreign fetch will land. And moving to foreign fetch is making us closer to the (future) web. Hopefully the beauty of bridge.js and/or the way the music app is written is that a big part of where the service lives is hidden under the hood. For example, music currently use |this.fetch('my_super_directory/my_super_url/') all over the place, so REST calls all over the places. Currently the backend can live either in: - the container of <iframe>. - a Service Worker - a remote process Sadly communicating to a remote process can only be done using IAC today. Foreign fetch beeing not ready, as well as Service Worker fwiw. Using those kinds of fetch calls that can be served transparently from a local thread / an other thread/ an other process is a great and flexible way to move forward and prototype things. So in this case, as IAC will never be standardized and foreign fetch will eventually replace it, IAC is a tool to move us closer to the (future) web. It will be very easy to move from IAC to foreign fetch once it has landed - nothing deeply ties us to IAC. I do not like it much more than you. But moving forward sometimes implies using dirty tools. Not moving is the worst thing we can do, especially if the usage of a particular tool can be so easily replace by a standard way of doing this in the near future (realistically not before at least 6 monthes...) Vivien. > The other part of the "browser" is the browser chrome which is part of the > system app and I'm not sure whether it makes sense or is possible to change > the architecture of that without changing the architecture of the whole > system app. If there's a back end for browser chrome then it's the window > manager and changing the architecture of that sounds like a wider > discussion. > > Something we do need to discuss is whether we want to add support for a TV > form factor in the mainstream browser UI in Firefox OS as TV currently uses > a completely separate browser app. But that's going to have to be part of a > wider discussion about merging the TV system app into the mainstream one as > well. > > Ben > > On 30 November 2015 at 10:39, Michael Henretty <[email protected]> > wrote: > >> >> On Mon, Nov 30, 2015 at 11:22 AM, Wilson Page <[email protected]> wrote: >> >>> One thing that is left to decide on Music side is whether we can go >>> ahead with FE/BE split as separate apps running in separate processes (via >>> IAC). This is something Vivien has been playing with the last couple of >>> weeks. >> >> >> >> To be clear, right now the Browser in the smart phone is not its own app. >> Instead, the mozbrowser iframe that represents the browser "tab" is >> directly managed by the system on the same level as other app windows. TV >> on the other hand (if I am not mistaken) does have a separate Browser app >> that manages it's own tabs. I'm not sure if adding more apps to the recipe >> is what we want here, but instead less. Anyway, this is what's up for >> discussion. >> >> > ---------- From: *Vivien Nicolas* <[email protected]> Date: Mon, Nov 30, 2015 at 5:39 PM To: Benjamin Francis <[email protected]> Cc: Michael Henretty <[email protected]>, Wilson Page <[email protected]>, Tim Guan-tin Chien <[email protected]>, "Pastor, Alberto" < [email protected]>, Marcus Cavanaugh <[email protected]>, Gregor Wagner < [email protected]>, Francisco Jordano <[email protected]>, Justin D'Arcangelo <[email protected]>, Evelyn Hung <[email protected]>, Reza Akhavan <[email protected]> Thinking about it a bit more and trying to share what I meant more clearly: if you want to think about it the way I do, then you may imagine a separate in-process app, called windows.gaiamobile.org, that contains multiple separate views. That's more or less how much separations of concerns it should provide/enforce.
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
