ubuntu-push-devs team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

I've been trying to figure out why you don't consider the amount of work
"that much" when it seems clearly to me to be a huge project.  I think
that's because we have different domains of expertise.  I build client
software.  Setting up a webserver with redundancy and databases and
things like that is something that feels like work, it's not fun at all.
Requiring me to have more than a Wordpress blog site for my app is a big
ask.  I don't think that we should assume developers of apps can do all
of that.

When I asked a friend who does mobile apps about this and Google his
reply was approximately: "That's why there's no an industry of managing
push notifications for developers."  I don't think our solution should
encourage new businesses.

Ted

On Thu, 2013-08-08 at 18:09 -0300, Lucio Torre wrote:
> 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
>         
> 
> 
>

Attachment: signature.asc
Description: This is a digitally signed message part