ubuntu-push-devs team mailing list archive

[Lucio Torre <lucio.torre@xxxxxxxxxxxxx>]

We need unicast more than broadcast. We can build one with the other.

I dont want to follow the irc room analogy because it breaks badly. You
need to be able to address each device-user-app individually, however crazy
that sounds on irc, thats the requirement :)

The developer needs to get notified, and if they miss the notification (one
http call from the device) they can just not acknowledge it so the device
must send it again. It works without expecting reliability, as all the
operations are idempotent. If anything breaks just continue from the last
thing that worked.

I agree that we are pushing some work to the developer and that's bad. Buts
its not really that much.

And for some reason, which maybe i haven't gotten to it yet, its also how
google does it:
http://developer.android.com/google/gcm/gcm.html#register

Lucio.


On Thu, Aug 8, 2013 at 5:42 PM, Ted Gould <ted@xxxxxxxxxx> wrote:

> **
>
> Uhm, that sounds bad.
>
> If I understand it correctly you're saying that every app on every device
> gets a chat room.  The developer gets one invite to the room, and if they
> miss it, oops.  Then they can invite whom ever they want to the chat room,
> but can't uninvite anyone.  An app could request a new room, but then
> everyone would have to be invited again.  As far as I can see, developers
> can't request new rooms.  There will be, quite literally, billions of rooms.
>
> It seems to ignore the use case of a broadcast message.  A large usage of
> push messages seem to be advertising notices "20% of shirts for one hour
> only" to all your customers (people seem to find these "useful," not sure
> why).  In that case if I had millions of users of my app, I'd have to send
> millions of messages to the server.  That along with standard overhead of
> error checking sounds like something that'd take more than the hour my sale
> is available.
>
> In general, I also have an issue with the design philosophy that we should
> make things difficult for apps and/or on the client.  We want something
> very simple for app developers and we want something that works without
> apps or the devices being very reliable (bad Internet, power failures,
> etc.)  Even our application lifecycle is not really friendly to apps
> sticking around, we kill them quick!
>
> Ted
>
>
> On Thu, 2013-08-08 at 14:01 -0300, Lucio Torre wrote:
>
> Yes, except that your description of the problem also includes the
> solution. What i propose is that we dont manage chatrooms and make that
> something apps need to do by themselves.
>
>
>
>  Apps get registered with us, we deliver messages to anyone that knows
> about that registration.
>
>
>
>  We make it simpler to ourselves but harder on apps. But not that
> harder,as they still need to build the pieces and removing one indirection
> (the server calling the developer) makes it "simpler".
>
>
>
>  Not married to this idea, anyways.
>
>
>
>  Lucio.
>
>
>
>  On Thu, Aug 8, 2013 at 12:43 PM, Ted Gould <ted@xxxxxxxxxx> wrote:
>
>
> Let me try to rephrase so that I'm sure I understand.  I'm going to use
> IRC terminology because I don't see a better vocab, and I'm reasonably sure
> everyone understands it :-)
>
> Every developer has a nick connected to the server (which is
> authenticated) and every device has a nick that is connected to the server
> (which is authenticated).  There are applications, and each of these has a
> chat room.  The developers are admins of these rooms, and every device that
> has the app installed is connected to that room.  If the developer wants to
> send something to everyone who has the app installed, they can put
> something in the chat room and everyone sees it.  Sometimes, they'll want a
> query to send to a specific device.  The developer needs to be able to get
> a list of everyone in the chat room to know who to query, but also get
> notified when people join/leave the room to keep their query list
> up-to-date.
>
> Is that a fair restatement?
>
> Ted
>
>
>
> On Thu, 2013-08-08 at 12:05 -0300, Lucio Torre wrote:
>
> Yes, although thats something that could be made to work, that not an
> important use case.
>
>
> But my point was more around the "notify developer that he needs to send
> stuff to the app"
>
>
> Having the Server contact the developer to alter the subscription status
> seems like we are adding more API than what we need.
>
>
> The key issue here is that the developer does not push to the application.
> He pushes to the user-device-application. So he needs to be notified of
> every install/uninstall by us.
>
>
> I think that in the long run all apps will talk to their developers to
> agree on something, so trying to capture that seems too much work.
>
>
> Lucio.
>
>
> On Thu, Aug 8, 2013 at 11:46 AM, Ted Gould <ted@xxxxxxxxxx> wrote:
>
> On Thu, 2013-08-08 at 10:59 -0300, Lucio Torre wrote:
>
> On Thu, Aug 8, 2013 at 10:00 AM, Ted Gould <ted@xxxxxxxxxx> wrote:
>
> I'm not sure what you're meaning here by token.  It seems like you don't
> need tokens as much as you need to authenticate everyone connecting, and
> keep a list of what they're allow to see and/or post.  I don't think they
> need to be tokens of any type as long as everyone authenticates to the
> server where the lists are stored.
>
>  Tokens are just a way to do that without having to keep a list of
> everyone that could be posting. The app-3rdparty communication still needs
> to happen so the 3rd party needs it needs to start notifying the app.
>
>
>
> Perhaps, I'm confused a bit on what problem we're trying to solve.  I
> figured we were looking at something like this:
>
>
>
> Which seems like the only auth is that the developer is allowed to push to
> any application that he/she also own.  And then the device can filter out
> specific application pushes.
>
> Are you saying that the use-cases are more like this though?
>
>
> I'm not sure how apps would really use that.  Do you have any use-cases
> there?
>
> Thanks,
> Ted
>
> --
> 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
>
>
>
>
>
>
>
> --
> 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
>
>
>
>
>
>
> --
> 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
>
>