On Aug 9, 2013, at 5:53 PM, Nick Alexander <[email protected]> wrote:
> On 13-08-09 5:35 AM, Lloyd Hilaiel wrote: >> Yo all, >> >> In a recent letter to the identity team I proposed breaking down the >> team by well defined projects, and having single leadership for each >> project. > > I think this is reasonable, but more below. > >> So how does this relate to the sync effort? I propose effective >> immediately we decompose this problem into the following groups with the >> named leaders: >> >> 1. (dcoates) Picl Authentication Server (including scrypt helper) - This >> is the current server that speaks a REST API, serves no content, and >> allows one to authenticate and access key material >> >> 2. (jedp) PiCL Auth Bridge - This is a facilitation server that allows >> us to build UI in HTML that interacts with the authentication server. >> It will be used in any environment where we get benefits from HTML as >> the UI (web, firefoxos, and maybe even desktop, more on this in a >> subsequent email). >> >> 3. (lloyd) Client Implementation - This is implementation for desktop >> and mobile that will land in mozilla central. I name myself as the lead >> here, but this is going to be a large cross functional group. (another >> email about this). > > While splitting into functional groups is a Good Thing, this doesn't reflect > the reality on the ground. Desktop and Android just aren't that similar. We > write code in different languages, for different runtimes, that execute with > different platform assumptions. To be clear, I'm not over-zealous about code sharing here in the slightest, but I am thinking about integration testing. The nice thing about elm is that we've got nightlies generated there. At some point in the near future how nice would it be to download a couple nightlies from the elm tree and be able to try out the experience on both devices? Also, because there's not necessarily all that much overlap, we can coordinate work in the same tree without stomping on each other. And two tiny short term examples where code sharing makes sense is native PBDKF2 & scrypt implementations. > FirefoxOS is another beast again. My belief is that each platform's client > team will work more closely with the Auth server team than the other client > teams. See my email on implementation approaches for a curve ball :). >> 4. (chris karlof) Future Storage Implementation - This is defining the >> simplest storage protocol that can work reasonably across our initial >> data types, bound by the MVP definition. > > 5. (ryan kelly) Storage Server implementation? Kind of a big deal. +1 lloyd > Nick > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
