webapps team mailing list archive

[Alexandre Abreu <alexandre.abreu@xxxxxxxxxxxxx>]

Give us the Edit rights :)



On Wed, Apr 23, 2014 at 2:39 AM, Justin McPherson <
justin.mcpherson@xxxxxxxxxxxxx> wrote:

> 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
>>
>>
>