On Monday, March 11, 2013 10:30:19 AM UTC-7, Mitchell Baker wrote: > I'd loved to see a bit of discussion from the folks involved in the idea > of having of all of these services in one module. It might be the > right thing but i'd love to hear the pros and cons.
Most of the services we've deployed so far, and plan to deploy in the future, do the same kinds of things -- make background HTTP requests, handle certain kinds of failures, schedule timers, preprocess some UI XML during build, etc. There's a lot of benefit (and not a lot of cost) to developing these services in one place. From a practical standpoint, of course there's code sharing and runtime work sharing, as well as big wins in testability, continuous integration, Android compat, documentation, and development environment setup. Nick in particular has spent a huge amount of time over the next nine months fleshing out a toolchain and docs for getting new contributors up and running building Android code, which is no mean feat. At a higher level, I think it makes a lot of sense to have a shared pool of knowledge for how to solve the kind of problems we're addressing in doing background work on Android. To me, those are the two defining characteristics of a dev module: shared code and shared knowledge. And to a point, what we're doing here is putting a name on what we've already been doing for months -- and that's already working well -- and trying to make sure that it continues to grow in a stable fashion. The downsides I see: * Inertia/gravity to continue accretion past the point that it makes sense. Arguably the same thing is true of toolkit to an even greater extent. I'm not too worried about this; Firefox for Android has a much bigger gravity well, and I think we've got a well-delineated scope. * Growing repo size. We've already addressed this for the Bagheera client for FHR on Android through sensible internal partitioning, and of course our existing m-c codebase is monolithic and abysmal in this regard, so we have a very long way to go before this is a problem. > My belief is that this is not a submodule for Fennec. Much of this is > standalone Java code that isn't inherently app specific, and could be used to > support multiple/different applications. To me, the closest equivalent for > this module would be Toolkit, which is generally where this type of code > lives for desktop apps. Indeed, the Android Services module can be built, deployed, and largely tested without Firefox being installed on the device; that's been true since its inception in October 2011. I'm not sure whether I'd pick Toolkit or NSS as an analogy, but I think you get the idea. _______________________________________________ governance mailing list [email protected] https://lists.mozilla.org/listinfo/governance
