ubuntu-push-devs team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Tue, Sep 10, 2013 at 6:59 PM, Robert Park <robert.park@xxxxxxxxxxxxx> wrote:
> CC'ing Ken VanDine since he's a Friends stakeholder and I'm not sure if he's
> on this list.
>
> On Tue, Sep 10, 2013 at 8:38 AM, John Lenton <john.lenton@xxxxxxxxxxxxx>
> wrote:
>>
>> On Tue, Sep 10, 2013 at 4:31 PM, Robert Park <robert.park@xxxxxxxxxxxxx>
>> wrote:
>>
>> > What is the status of push development? Is there any documentation that
>> > I
>> > can read about it?
>>
>> not much at this point, although there is a bit and we're working on
>> more. We've got a plan, or a plan for a plan, and are writing that out
>> and making sure it's sane before executing it.
>
>
> Ok. I'm still trying to figure out what Friends is going to even need to
> look like in order for this to be workable.
>

Can you clarify the specific use-cases you are trying to
solve/referring to here? As I understand it, friends will only
eventually migrate to the push-notification service and we are good
with what we have right now. Admittedly, polling on a socket is not
what we should or want to do, but we are not limited by implications
of the app lifecycle for friends.

> The current situation is that we have one local daemon that is written in
> not-python which does efficient memory management of a small db of social
> network messages, and then we have a local python script which, when invoked
> periodically by the daemon, polls your social networks and submits messages
> into this db. Then we support arbitrary client frontends that can connect to
> this db and display messages. Known frontends include the unity friends
> lens, community developed ubuntu-facebook-app, and our own friends-app.
>

Let's assume the best case and we have native apps for facebook,
twitter, your-favorite-social network apps. How would friends fit in
with this configuration/scenario?

> In a previous email you told me that the polling bits would need to move off
> the phone, and at first glance it seems as though the local daemon and the
> python script are modular enough to just get bumped off the phone and onto a
> server in the cloud somewhere, ***except*** that I foresee a slew of
> problems:
>

I might be missing context here, but I wonder if dedicated apps would
integrate with friends at all. Can you clarify the situation?

> * All of our components are communicating with DBus. I am vaguely aware that
> DBus can be used over the network but I have no idea how well it works or
> what challenges I might face there.
>

I would assume that all our marshalling code is abstracted and that we
are able to switch to a different serialization format. More to this,
DBus is an implementation detail and I would again assume that our
interfaces are not exposing any sort of transport/communication
mechanism to plugins/client applications. If those assumptions are
true, swapping out the communication mechanism is a finite and
manageable task from my POV.

> * Everything we do depends heavily on Ubuntu Online Accounts in order to
> authenticate with the user's social networks and download the messages we
> poll for. How will I go about sending the user's social network OAuth tokens
> to a server process running in canonical's/operator's cloud, and what are
> the security/privacy implications of this? The community screamed bloody
> murder about our central server for dash queries, just wait until they hear
> that we're gonna be harvesting their social network credentials.
>

We are not, again, let's clarify the use-cases and see how friends
fits in with a scenario where we have dedicated apps for social
networking.

> * If we end up using an interchange format such as JSON for transmitting
> social network messages from our server to the phone, then the phone needs
> to retain all the JSON-parsing code that I've already written, and it seems
> like a massive duplication of effort. Eg, social network sends JSON to
> canonical/operator server, which gets parsed and interpreted and marshalled
> into a standard format, and then converted back to JSON, and pushed to the
> client, which interprets the JSON again. Adds an extra hop in the
> transmission of the data.
>

I'm not sure I'm following here. What is your underlying concern?

> * Authentication! how the heck is the server gonna know which messages go to
> which people! So I'm gonna have to create a whole new authentication layer
> myself? And we expect every app author to reinvent this themselves? Or will
> you be providing an SDK for authenticating clients to the push server in a
> reliable and secure way?
>

This obviously needs to be part of the SDK and the push-service needs
to provide a consistent way for authentication and encryption.
I think it's important to consider the per-app use-case here. friends
is a somewhat special case from my POV. (John, please correct me if
I'm wrong).

Thanks,

  Thomas

>>
>> > I had a look at https://launchpad.net/~ubuntu-push-devs but there's no
>> > code,
>> > no bugs, and no blueprints, which is less than ideal.
>>
>> there is a blueprint!
>>
>>
>> https://blueprints.launchpad.net/ubuntu/+spec/client-1308-push-notifications
>
>
> It's hiding ;-)
>
> --
> Mailing list: https://launchpad.net/~ubuntu-push-devs
> Post to     : ubuntu-push-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-push-devs
> More help   : https://help.launchpad.net/ListHelp
>