On Wed, Feb 19, 2014 at 3:31 PM, Adam Roach <[email protected]> wrote:
> (Sorry for the long subject -- I think we have a project name picked out,
> but since it hasn't been officially communicated yet, I'm using the
> descriptive term "User-Facing WebRTC Project.")
>
> Based on conversations this morning, we have a number of decisions and
> pending action items for the user-facing product architecture. These are
> summarized below. I've marked action items with a single letter to indicate
> the associated timeframe: "L" for "MLP", and "V" for "MVP" [1].
>
> I have action items recorded for Mark Banner, Nicolas Perriault, Dan
> Mosedale, Eric Rescorla, Alexis Metaireau, and myself.
>
>
> Client Architecture
>
>
> Decisions
>
> * The panel JavaScript will ship with the browser and ride the trains,
> at least through MVP.
> * Local data storage will make use of the IndexedDB API. We may choose
> to wrap it to make it less painful to use.
> * Unit testing of client code will be performed with the mochi test
> framework.
>
>
> Action Items
>
> * L: *Adam* to contact Gavin, Dolske, and Shane to determine future
> availability and support for Social API
> * L: *Mark* to experiment with loading chrome: URLs in the Social API
> to determine whether doing so gives us sufficient elevated privileges.
> * L: *Nicolas* to examine use of client libraries (jQuery, Backbone)
> to determine how much effort we're likely to save versus the effort
> of ensuring we can run the libraries safely in the context of
> elevated privileges.
> * V: *Adam* to research possibilities for running part of the code
> with chrome privileges and others with content privileges, so as to
> minimize the exposure to security issues.
> * V: *Dan* to evaluate the use of <template>s for the use of l10n
> (will all WebRTC browsers have template support?).
> * L: *EKR* to touch base with Doug to determine tools used to test
> Sync, evaluate applicability to our use cases.
> * L: *Adam* to contact David Burns and Ted to determine the level of
> effort it would take to make Marionette and Steeplechase work
> together, to facilitate system testing.
> * L: *Adam* to ask Ted who to contact regarding the prospect of
> running a subset of Mochi tests on Chrome/Chromium.
> * L: *Adam* to talk to Andreas and Denelle about partner library code
> landing and versioning.
>
>
> Server Architecture
>
>
> Decisions
>
> * Development will be performed in node.js
> * No external libraries are identified for use at this time. Any
> external libraries will be discussed and agreed upon before importing.
> * Current assumption is that we will use AWS for deployment. This can
> be revisited if circumstances arise that makes that deployment
> environment suboptimal.
> o As an aside, the ability to run the server code locally is a
> hard requirement.
> * We will use github pull requests to ensure that patches are reviewed
> prior to landing.
>
I missed this decision, but it's not really matching what I would have
expected.
Rather, I would have expected that every patch would correspond to
a bugzilla bug, that we would do reviews in bugzilla, and github pushes
would come with r=<foo> as we do now...
-Ekr
Action Items
>
> * L: *Adam* to task appropriate party with evaluation of available
> databases.
> * L: *Alexis* to create repo in under mozilla github; *Adam* to send
> him list of team members so they can be added to the committers.
> * L: *Mark* to investigate state of github/bugzilla integration.
>
>
>
> ____
> [1] That's "Minimum Landable Product" (aka demo) and "Minimum Viable
> Product" for anyone not used to these acronyms.
>
> --
> Adam Roach
> Principal Platform Engineer
> [email protected]
> +1 650 903 0800 x863
> _______________________________________________
> dev-media mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-media
>
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
