ubuntu-phone team mailing list archive

[Christian Dywan <christian.dywan@xxxxxxxxxxxxx>]

On 18.11.2014 08:24, Alberto Mardegan wrote:
> On 11/18/2014 04:17 AM, Robert Park wrote:
>> This has been an enormous problem for webapps through the life of the
>> project and we've had to constantly sru simple fixes for things that
>> changed in remote servers we don't control. Shipping that kind of thing
>> as click packages is absolutely the right way to go.
>
> Well, that's because in webapps we targeted a specific implementation
> of the website, which is undocumented and can change at any time.
> Authentication parameters don't change that often, and when they do,
> at least Facebook and Google send out deprecation warnings several
> months (if not years) in advance.
> That said, I certainly see some value in having these providers as
> click packages, but there's also one issue to consider: as long as
> they are deb packages, they are a nearly unremovable part of the SDK
> framework, and apps can rely on them being installed. If we package
> them as clicks, this assumption can break. On the other hand, I
> believe that even if the account plugin is not installed, the
> application won't crash or behave too badly anyway, so this wouldn't
> cause to big issues.
Could account plugins in general be uploaded separately from their apps?
That would reduce the need for manual review and allow the app itself to
update automatically.

This would presumably need some sort of "open store if plugin missing"
behavior in the app - at the same time, it could be re-used for "plugin
broke but you don't have the update yet, please update now". When you
have a ton of updates and eg. on a slow connection this can be a life
saver if you would otherwise refrain from updating anything.

ciao,
    Christian

Attachment: signature.asc
Description: OpenPGP digital signature