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. I'm not sure #3 is necessary since core devs /
QA have historically tended to use AWS for testing
I'm concerned that if we're not using it, it won't get maintained. Is
that a reasonable concern, or do you think we'll be able to handle that
burden?
...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. :)
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?
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?
Thanks for the thoughtful feedback,
-Callahad
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
