[Oneiric-Foundations-Topic] networked client app updates

[Nick Pavlica]

Allison,

On Thu, Apr 21, 2011 at 9:14 AM, Allison Randal <allison at canonical.com>wrote:

> The Ubuntu One developers have an interesting technical conundrum that
> would benefit greatly from all of your thoughts. They've started
> collecting ideas, and would like to collect more, and hopefully settle
> down on a plan for the next cycle in a UDS session.
>
> The basic problem is in keeping a networked client in sync with a
> networked service. In the wider world this is generally handled by
> releasing an update for the client whenever the service changes. Ubuntu
> One has been tying the development cycle for their service to Ubuntu's
> six month cycle, so client feature updates only happen in new distro
> releases. But, even that doesn't quite work, because once you change the
> service then clients on older distro releases (especially LTSs) still
> need the feature updates to connect to the updated service. Sometimes
> these feature updates depend on newer versions of libraries than exist
> on the older distro releases.
>
> The category of lightweight client apps for a remote service is becoming
> more and more common, so ideally a solution for Ubuntu One will be one
> we can recommend to all app developers. Here's a grab bag of
> brainstorming so far:
>
> - Only ship a very small shim for the client on the CD (advantage of
> small footprint), and do the rest of the install the first time someone
> uses Ubuntu One.
>
> - Ship Ubuntu One client in extras, backports, commercial, or partner
> repository. (Better if it's on by default than requiring a manual step
> to enable the repository.)
>
> - Ship Ubuntu One client (only) in a PPA.
>
> - Implement "self updating" within the client, similar to
> Firefox/Thunderbird (on non-packaged installs). This is the most complex
> technically, so not the most appealing.
>
> - Pull some update dependencies into /opt/.../UbuntuOne/lib, to keep
> them completely isolated from the rest of the system, but available to
> the Ubuntu One client.
>
> Do you all have more ideas or suggestions?
>
> Allison
>


The inherent flaws in tying client releases to each Ubuntu release are
obvious as you illustrated above, it's just not a good idea.  For example, I
have the the same version of Dropbox running on multiple versions of Ubuntu,
offering a consistent set of features and behavior.  That being said, It's
my opinion that the Ubuntu One client(s) should be self contained, and
consistent across Ubuntu Distribution releases using the last LTS as the
baseline, then move forward from there.  When the next LTS is released you
could move the baseline forward if needed and stop support for older
versions of Ubuntu so that testing and development have a reasonable scope
of support.  Additionally, the dependency on specific versions of libraries
like CouchDB that are shipped with Ubuntu can cause issues with
other applications/developers.  For example, if a user want's to install a
different, or newer version of CouchDB there is concern that it will break
Ubuntu One which is not acceptable for users that rely on Ubuntu One
services.  In fact, I have customers that use Ubuntu One services as a
critical component of their business process.  Additionally, I think that
it's a good idea to ship the Ubuntu One client(s) as part of the
distribution,  as this makes upgrades and new deployments easier and faster.
 If it's a new installation, you could disable the daemons by default for
security and resource reasons and activate them once the machine is
activated.  Obviously if it's an upgrade all of the daemons would be enabled
at startup.  I hope this feedback helps.

Thanks!

-- Nick Pavlica




>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20110425/70923d8b/attachment.html>