Absolutely - how we implement the changeable views is an engineering call till now I only had one option and that was the FE/BE split.
If there are different technical options then even better - just need to understand the pros and cons. - for me its critical that we have a adaptable, modular architecture that will allow people who use our OS to modify to their need. BR Wilfred > On 23 Nov 2015, at 15:11, Vivien Nicolas <[email protected]> wrote: > > On Mon, Nov 23, 2015 at 3:16 PM, Andrew Sutherland > <[email protected] <mailto:[email protected]>> wrote: > On Mon, Nov 23, 2015, at 06:08 AM, Vivien Nicolas wrote: >> Actually Francisco keeps complaining that there is not enough people pissing >> on Service Worker ware, nor the Virtual list. Having more feedbacks to >> understand why a particular library does not fit your use case is great. >> Having patches to make it fit your use case is awesome. But in general those >> libraries are open to discussions. >> So, your "a-la-carte" wish, is basically what Francisco says since the >> beginning! > > To be clear, I agree: Everyone has been very open to discussion and as an > FxOS engineer I have not felt pressured to formally adopt NGA for the sake of > NGA. If things continue like this, we're in great shape. If we all mail the > mailing list a little bit more, we're in even better shape. > > My specific concern is a combination of nitpicking on Justin's specific > phrasing of "follow" and that Wilfred's root message in this thread and his > follow-ups seem to very explicitly be a prescriptive "everybody adopt NGA for > the sake of NGA" which is a change from this. > > > I think Wilfred point is: it should be easy to replace any views. For us at > Mozilla, as the shape of the future product is not defined, for partners as > they may want to customize things, for third party as they may want to have > fun. > > Now, I don't think Wilfred or others are really pushing for one specific > technical solution. > > But so far 'NGA' is likely what they have been told will help for some of > those specific issues, as well as some others. Then it sounds logical to them > that they want to move forward, trying to break the architecture proposal > into multiple parts that can be incrementally worked on while trying to > define a product. > > >> This answer will likely contradict a bit the "a-la-carte" point and the >> feeling that any app owner can do whatever it wants, when it wants - or when >> it feels it is time. > > To clarify, I'm not suggesting module owners should get to be dictators of a > fiefdom and should work on what suits their whim. All of the aspects of NGA > are meant to address different problems we may encounter. I think it makes > sense for product/UX/foxfooders/engineers to agree on the biggest problems in > apps and prioritize them. > > For example: "Check out this profile, your app is unresponsive during normal > usage because of too much main-thread work and we need to move things to a > worker ASAP" is a great reason to do an overdue FE/BE worker split. "All the > apps need to be on NGA" is not. > > "I was trying to figure out how I could create a tablet version of this > screen without forking the app, and I couldn't because the view logic and > application is too entangled" is likewise a great reason to focus on > solutions to that problem. Other internals issues that impact potential > contributors are also important, and this is a place where arguments for > consistency should definitely be considered with the trade-offs. > > > Those are great examples. I bet all of the app authors have a few lessons > learned in the past years, and some stuffs they have been struggling with. > This is some of those that we should solve with some architectural changes. > > Usually one solution does not fit all, and there will likely be some > differences into apps architecture in the future, but at least it would be > great to have a high level architecture common to most apps. > > One of the things the proposal is trying to do is to draw some white boxes. > Authors can freely address their specific issues into them. Those boxes are > delimited via platform primitives such as compartments, threads or processes. > > > Hopefully I'm misunderstanding the original intent of the thread. If the > idea is that that the NGA group will help identify specific > user/developer/contributor pain points in apps and specific NGA solutions and > will talk with the relevant parties (product, US, engineering, etc.) about > priorities and trade-offs, then that is awesome. If we're talking about > prioritizing checking a bunch of boxes for the sake of checking a bunch of > boxes, I'm concerned, and I think that may be the concern of others as well. > > We are talking about moving forward in an uncertain environment, and to offer > a flexible enough Gaia so it can fit into multiple variants in a quick, > stable and performant way. > > Thanks for raising your concerns thought. I'm pretty sure you are not alone > to feel this way. > > Vivien. > > > Andrew > > _______________________________________________ > dev-fxos mailing list > [email protected] <mailto:[email protected]> > https://lists.mozilla.org/listinfo/dev-fxos > <https://lists.mozilla.org/listinfo/dev-fxos>
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
