ubuntu-push-devs team mailing list archive

[Robert Park <robert.park@xxxxxxxxxxxxx>]

On Tue, Sep 10, 2013 at 10:17 AM, Thomas Voß <thomas.voss@xxxxxxxxxxxxx>wrote:

> On Tue, Sep 10, 2013 at 6:59 PM, Robert Park <robert.park@xxxxxxxxxxxxx>
> wrote:
> > 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.
>

Use case: "Somebody sent me a message on Facebook" --> "I get notified
about that message on my Ubuntu Phone/Tablet/Desktop/ConvergenceDevice"


> > 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?
>

Gosh, I wish somebody would have told me this a year ago, I could have
saved myself the trouble of writing Friends in the first place!

The thing you have to understand about Friends is that it is a direct
descendant of Gwibber. The use case for Gwibber had always been "We want a
nice desktop application that allows us to interact with our various social
networks in one unified place, including desktop notifications." Then along
came our convergence story, and the use case became "We want a nice
application that allows us to interact with our various social networks in
one unified place, including notifications... whether it's on a phone or
desktop or whatever." and thus friends-app was born.


> > 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?
>

Well it's unlikely that a Facebook app written by Facebook would integrate
with Friends at all. But community-driven ubuntu-facebook-app is nothing
but a frontend to Friends that hides non-facebook messages and attempts to
provide more facebook-specific features that wouldn't make sense inside
Friends itself (Friends is aimed at being a lowest-common-denominator among
many social networks).


> > * 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.
>

DBus is hardly an implementation detail. The db that we are storing our
messages in is Dee, which is literally a db built *inside* dbus. dbus is
the only way to get messages into or out of it. It's entirely how we're
able to show the same social network messages inside the unity dash, in
friends-app, and in ubuntu-facebook-app. Take away dbus and we basically
have nothing. So we have to continue using that locally, but we need to use
something else for receiving our push messages, which means we're going to
need a new glue layer to interpret the push messages and store them in Dee.

> * 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.
>

So basically, the feeling I'm getting from you, is that friends should not
exist and therefore don't worry about it. Is that correct?


>  > * 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?
>

The concern is that the push server, which will be acting as an
intermediary between the social network and the ubuntu device, is not
actually going to cut down on much overhead if it's just sending us 'raw'
JSON the way the social networks already do. Sure we benefit from not
polling, but instead of just having a phone parsing huge blobs of JSON, we
would then have a server parsing huge blobs of JSON, pushing JSON blobs to
a phone which still needs to parse huge blobs of JSON. There's no benefit
of pushing our JSON-parsing code into the cloud if we still have to parse
JSON on the phone anyway.

So current architecture looks like this:

Facebook --JSON--> Friends --DBus--> friends-app

I was hoping push might look like this:

Facebook --JSON--> Push Server --DBus--> friends-app

But instead it's looking like we're going to end up with this:

Facebook --JSON--> Push Server --JSON--> Friends --DBus--> friends-app

It's just an extra hop, an extra layer of JSON parsing, and doesn't offload
as much from the phone as I was hoping would happen.