← Back to team overview

ubuntu-phone team mailing list archive

Re: Background services: a problem that we need to face

 

On 06/25/2014 08:15 AM, John Lenton wrote:
> On 25 June 2014 12:49, Jamie Strandboge <jamie@xxxxxxxxxxxxx> wrote:
>>
>> With this example, who writes and is in control of the remote service (eg, IRC
>> bouncer)?
> 
> typically when you have a chat client, the chat server interoperates
> with the push server. In the case of IRC, the people running the IRC
> server could do expose an API that the IRC client uses. If the people
> running the server don't want to do that (and I'm assuming they're not
> interested, or there'd be services for non-ubuntu smartphones
> already), then you need some kind of mediation, a bouncer, and you'd
> need to trust it enough.
> 
> Or you could have a generic bouncer that joins the channels you join,
> but you'd miss out on private messages.
> 
Historically for irc, people have wanted a persistent chat session that they
could connect/disconnect from and so bip (and presumably other software) was
born. I guess someone could write an irc client that could talk to a push
notifications-aware bip (or whatever) server would work for phones. It sure
would be nice if we could get rid of the requirement for the extra server
though... (which gets back to needing the service on the client).

Earlier in the thread it was mentioned that telepathy(-gabble) could be updated
to be push-notification-aware for XMPP. I guess the way to do this would be to
have telepathy-mission-control would need to have apparmor integration so that
apps could only access their own configuration/conversations/logs/etc. If done
right, that probably shouldn't be too bad to add and could be done generally for
any telepathy backend (including IRC)-- it is basically what online accounts is
doing now. OTOH, I don't think telepathy-mission-control would have to be a
trusted helper so long as apps are only allowed access to their own
data/conversations/configurations (if someone is going to look at this-- match
by click package name, not the full APP_ID. One way to get the click package is
deriving it from the APP_ID with split(APP_ID, '_')[0]).

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

Attachment: signature.asc
Description: OpenPGP digital signature


References