← Back to team overview

ubuntu-phone team mailing list archive

Re: Thoughts on inhibiting app suspend via application lifecycle

 

On 10/23/2013 08:27 AM, Ted Gould wrote:
> On Wed, 2013-10-23 at 11:09 +0200, Thomas Voß wrote:
>> On Tue, Oct 22, 2013 at 8:45 PM, Rasmus Eneman <Rasmus@xxxxxxxxx <mailto:Rasmus@xxxxxxxxx>> wrote:
>> >>my point of view is still that forcing every little small app to bring its
>> >> own
>> >>daemon will:
>> >>
>> >>a) scare off people for writing apps for our platform as the communication
>> >>overhead between a service and the UI is a huge effort and easy to mess up.
>> > Android have AIDL (http://developer.android.com/guide/components/aidl.html)
>> > to help developers with this, I have used it and have to say that it's very
>> > simple
>> > to use. Hopefully something like this could come to Ubuntu too (it would
>> > make
>> > sense on the desktop as well).
>> >
>>
>> AIDL is *another* middleware that helps in implementing an
>> out-of-process component model. That being said, we will need
>> something comparable. And before people start asking: I think we need
>> to help developers with a layer on top of "raw" dbus to make this as
>> convenient and easy as possible. We can probably hijack existing
>> object hierarchies, but might as well come up with something that is
>> less coupled to a specific object model.
> 
> I realize that this isn't exactly what you're saying, but I don't think we want
> to necessarily use DBus here, at least on a well known bus (session).  We've
> restricted the use of well known names (which is good IMHO) but that makes
> finding your background service slightly difficult.  It seems like what ever
> protocol goes across it, doing something that only relies on flies in the
> application's cache directory I think would be more robust.
> 
> I think that we also need to ensure that what ever defines the background
> service doesn't imply that protocol.  For instance a background service that
> just writes to an SQLite DB seems valid to me.
> 

DBus is going to be problematic from an application confinement point of view
unless we can someone restrict the bind, path, interface, etc to application
specific values.


-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature


References