On 6/17/14 18:23, Francois Marier wrote: > On 18/06/14 04:07, Dan Callahan wrote: >> 0. Are those the right goals? Am I unnecessarily conflating anything? > > I really like #1 and #2.
One thing I forgot to say with respect to goal #1 is that I think a target of 1 or 2 hours would be fine too. It's probably a lot easier to achieve than 15 min :) On 18/06/14 13:11, Dan Callahan wrote: > ...and I'm also experiencing some resistance to devoting engineering > time to support self-hosting. Specifically: skepticism about the whether > self-hosting delivers meaningful user value, as well as concern over the > ongoing maintenance workload and the engineering opportunity cost. The > idea of a project that benefited both us *and* self-hosters was more > palatable. > > So finding something that addresses all three would be ideal, but they > may be mutually exclusive. Hence the request for feedback. :) That's interesting. IMHO, self-hosting is a very good litmus test for whether or not a given service is a silo. It won't bring measurable user value like a higher number of FxA users, but I feel it will give more credibility to our product (and more generally to the work that our team does) from a mission point of view. >>> 3. Would you, yourself, use the above system for local development or >>> testing? Why / why not >> >> No. "git clone" and "npm install" is all I've ever needed for >> development. > > Not anymore. ;) > > The difficulty of self-hosting Sync is that it now requires 3 Node.JS > servers (auth + content + verifier), 2 Python servers (token + storage), > and one or two databases (auth + storage). > > And all of them have to share secrets and know about the others. > > Does that change your opinion on any of this, or do tarballs still seem > right? Well, I don't work on Sync, so I personally don't need to worry about the Python pieces :) The database point is interesting though because that's a good example of something that is very different between development (where you probably want a disposable in-RAM database) and self-hosting (where you need persistent data ideally in MySQL/Postgres). >>> 4. How should we package and distribute the services? >> >> So my recommendation would be tarball releases with: > > How would you split things up for tarball releases? All 5 servers in one > tarball, one per server, one per language, or something else? Reflecting a bit more on this, we can break down what we need into three things: 1. some working code (which we have on github) 2. an upstream project with releases 3. a way to install releases (e.g. binary packages in distros) My main point was that we should focus on #2 and mostly ignore #3. However, looking at what happened with Old Sync, we never had a proper #2 and instead OwnCloud showed up and solved that problem for us. (It then made it to Debian, solving #3 too.) So perhaps the best way forward would be to help OwnCloud (or a similar effort) as much as we can and make that the recommended way to self-host NewSync? Francois _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
