webapps team mailing list archive

[Justin McPherson <justin.mcpherson@xxxxxxxxxxxxx>]

You can see a brief overview on what things might look like here; <
https://docs.google.com/a/canonical.com/drawings/d/1hzVy3CT81C7Ghbowi0hhL8PoyfdvXUiLrAm2Qt_CMtI/edit?usp=sharing
>

Feel free to edit/comment.


- Justin



On Sat, Apr 19, 2014 at 12:40 AM, Alexandre Abreu <
alexandre.abreu@xxxxxxxxxxxxx> wrote:

> 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 ...),
>
>
>
>>
>>
> --
> Mailing list: https://launchpad.net/~webapps
> Post to     : webapps@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~webapps
> More help   : https://help.launchpad.net/ListHelp
>
>