webapps team mailing list archive

[Alexandre Abreu <alexandre.abreu@xxxxxxxxxxxxx>]

On Tue, Apr 15, 2014 at 10:58 AM, Alberto Mardegan <
alberto.mardegan@xxxxxxxxxxxxx> wrote:

> Our unity-chromium-extensions is using the NPAPI which has been
> deprecated last year and will soon stop working (updates will be blocked
> already in May!)[0].
>

definitely ! we had this in mind since early 2014,

the deprecation will come soon now (starting w/ Linux as always w/ upstream
chromium),


>
> When planning for a replacement, I'd like we put some efforts in
> integrating the Online Accounts experience as well, in order to minimize
> the amount of extensions we produce.
>

Agree, the thing is now the extensions perse are way more minimal than what
they were previously, so more manageable (some cleanup is still necessary),
so adding OA into the mix wont make explode,


> For the record, the existing (but not used) Online Accounts extension is
> here (both for Firefox and Chromium):
>
> http://bazaar.launchpad.net/~online-accounts/webaccounts-browser-extension/trunk/files
>
> From the Online Accounts POV, the required informations are: the domain,
> the username (or anyway an identifier for the user, though we might even
> do without it maybe) and the cookies.
> The cookies can be obtained with a specific extension[1], and I believe
> that they should be useful for the webapp story as well, if we manage to
> reuse them the first time that the webapp is started.
>
> My impression is that we should have an extension which is as slim as
> possible: only captures the required information, and then delegates all
> the work of setting up the webapp (and creating the online account) to
> an external process. In this way we can hopefully share as much code as
> possible with the Mozilla extension.
>

well as much as we can yes, but from experience code sharing has always been
quite tricky in those areas a minimal (we tried since when I joined) since
the 2
structure and logic do follow very different flows,

we can share (as we do already) some helper/small functions or possibly
some classes
that encapsulate units of logic (that do not interfere w/ the flow, e.g.
cookie manipulation),


After a very quick glance at the options, I find the Native Messaging
> extension [2] the most suitable for our needs, because my understanding
> is that a NaCl would be confined, and it's not clear to me in which
> ways. But that's just my first impression.
>

this is what we had in mind already, Justin did some experiemnts w/ it and
it
is what is recommended by upstream as a replacement (and is out of process
which
is good crash wise),

The things though, is that there is one thing that we should think about.
We dont inject
scripts anymore in the extensions. They are mostly used to install the
webapps that we
support and do some light management.

Now, we would need to reinject some script to access the DOM & capture the
userid & cookies.
Those would be lighter than the one used previously. We would need a to add
them to the webapps
packages in a meaningful way (or reuse the same script in line 2 different
mode? might make
things more complex for nothing ...),



>
>