ubuntu-push-devs team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

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

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