[15:57] <popey> https://plus.google.com/hangouts/_/72cpimpvpi9rolli0mdagesc0o
[15:57] <popey> ^^ url for the next session
[16:01] <nik90> popey: just a note, the summit page http://summit.ubuntu.com/uds-1311/meeting/22105/appdev-1311-push-notifications/ shows the wrong irc channel
[16:01] <nik90> it is pointing to appdev-1 instead of appdev-2
[16:02] <olli> somebody got the HO URL for me
[16:02] <popey> hmm
[16:02] <popey> https://plus.google.com/hangouts/_/72cpimpvpi9rolli0mdagesc0o
[16:06] <nik90> popey: you guys are live
[16:06] <popey> thanks
[16:07] <__lucio__> https://blueprints.launchpad.net/ubuntu/+spec/appdev-1311-push-notifications
[16:07] <olli> https://blueprints.launchpad.net/ubuntu/+spec/appdev-1311-push-notifications
[16:07] <Chipaca> olli: thanks :)
[16:08] <rickspencer3> is anyone from foundations and desktop here?
[16:08] <kenvandine> rickspencer3, i am
[16:08] <facundobatista> I hear *so much eco*
[16:09] <alecu> I hear a dog
[16:09] <alecu> and echo now
[16:09] <rickspencer3> kenvandine, can you speak for the update UI in the settings?
[16:09] <rickspencer3> or do we need seb128 for that?
[16:09] <kenvandine> seb128
[16:09] <kenvandine> i just heard about that this morning
[16:10] <kenvandine> rickspencer3, i could try if he can't though :)
[16:11] <rickspencer3> dang it
[16:12] <rickspencer3> olli, Chipaca can you guys paste me a link to join?
[16:12] <Chipaca> rickspencer3: https://plus.google.com/hangouts/_/72cpimpvpi9rolli0mdagesc0o
[16:13] <olli> thanks ricmm I was having connection issues
[16:15] <olli> https://docs.google.com/a/canonical.com/document/d/12_a-V9B_ethmVJPF8vtcY7Hs7kc-VP-OcIwRx5ZPmjI/edit#
[16:16] <karni> Doesn't it mean the phone would need to be talking to multiple push notification servers?
[16:16] <__lucio__> no.
[16:16] <__lucio__> at least not for the polling part. yes for giving the registration key.
[16:17] <facundobatista> karni, the push notification server will be only one
[16:17] <karni> I see. Thanks guys, reading the spec now
[16:17] <facundobatista> karni, then, there will be a lot of App servers
[16:17] <karni> facundobatista: gotcha, that makes sense.
[16:18] <lool> There are two server types: the application specific server, and the push notification server (Canonical/phone operator)
[16:18] <karni> Now I get it. At first it was quite confusing from the talk, now I see it's the same as GCM
[16:19] <lool> rickspencer3: we want to factor notifications
[16:19] <lool> rickspencer3: or drop notifications
[16:19] <lool> rickspencer3: or handle network load
[16:19] <facundobatista> rickspencer3, if each App would talk to their own server, you'll finish with 10 apps in the phone polling their servers => battery drain
[16:19] <karni> rickspencer3: We're leveraging a single connection for applications.
[16:19] <facundobatista> (sorry, no mic)
[16:20] <karni> I love this project. Pull me in! haha
[16:20] <karni> (the project, not the hangout ;) )
[16:20] <tvoss_> olli, rickspencer3 o/
[16:20] <knocte-uds> this is the way other mobile platforms work: only 1keep-alive connection to one server
[16:20] <olli> tvoss, pls join
[16:20] <karni> knocte-uds: correct
[16:21] <larsu> is anyone else having problems with the video stream?
[16:21] <karni> larsu: all good here
[16:22] <knocte-uds> it is a keep-alive connection, it's a big dela
[16:22] <knocte-uds> deal*
[16:22] <kenvandine> rickspencer3, there is no polling
[16:22] <karni> rickspencer3: To give you a reference, http://developer.android.com/google/gcm/gcm.html https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html
[16:22] <karni> (2 URLs)
[16:23] <karni> It's not a bottle neck. It's enablement.
[16:23] <ralsina_> each connection is extra wakeups
[16:23] <larsu> karni: are you in the hangout or watching the stream?
[16:23] <karni> larsu: watching. I think there's enough people already.
[16:24] <alecu> rickspencer3: every other mobile platfor(ios, android) does it with a centralized server to save on battery on the devices
[16:24] <olli> tvoss_, you there?
[16:24] <larsu> karni: right, me too. But I only get a blank screen
[16:24] <Azendale> Question: Just to make sure I understand, nothing on the phone is polling with this? The phone just opens a tcp connection, and then the server can send a message any time it gets an update for the phone?
[16:24] <knocte-uds> the server needs to call the client, so either the client polls, or the client has a keepalive connection
[16:24] <karni> larsu: reboot/restart browser/it's fine here :(
[16:24] <larsu> karni: haha "reboot the browser"
[16:24] <karni> larsu: reboot computer/restart browser bud..
[16:25] <larsu> ;)
[16:25]  * karni listens to the session :)
[16:25] <larsu> works in chromium. thanks.
[16:25] <karni> larsu: np. using chromium here.
[16:26] <alecu> rickspencer3: and perhaps "system updates" is not the most useful example to have instant notifications, but this infrastructure is useful for chat or other services where real time is needed
[16:26] <karni> __lucio__: The reestablishing SSL connection without the handshake each time (I don't know the details, though) is a very good and valid point. GCM send a heartbeat to the server as rarely as 5 minutes.
[16:26] <tvoss_> olli, joining now
[16:29] <karni> This is a neat "intro" to GCM in case anyone wants to ramp up http://www.youtube.com/watch?v=y76rjidm8cU
[16:30] <karni> (ramp up on the subject that is, I'm not a Google advocate or anything)
[16:30] <facundobatista> rickspencer3, we didn't found (yet) any other design, without a central server (that would be the Push Notification Server), that will give the results we want without draining the battery and network operator to allow our phones to use it
[16:30] <karni> Shared that just for reference.
[16:30] <karni> rickspencer3: That's the whole point of push. Live notifications.
[16:30] <karni> But such notifications that don't drain battery and abuse network.
[16:32] <Azendale> QUESTION: Will this single server that is being proposed be opensource and available to run on your own server? If so, will you be able to change the one push server the phone uses (I guess you can always recompile)?
[16:33] <karni> Azendale: (personal opinion) I think that would waste the whole effort of a single centralized server. I feel where your question comes from, though.
[16:34] <__lucio__> Apps wont know where to push notifications if you use a different service.
[16:34] <karni> You wouldn't have benefits of switching to a different server if the only app levereging that server would be yours. All other apps would not work
[16:34] <facundobatista> Azendale, you will not convince twitter, facebook, etc to send notifications to several servers, we need ONE centralized server
[16:34] <karni> because app servers would still be talking to our server.
[16:34] <karni> exactly what __lucio__ said
[16:35] <olli> brb
[16:36] <Azendale> karni: I think my main concern is that we can read the code that will have all our messages passing through it
[16:37] <karni> Azendale: ha, there's a twist here. you don't need to contain your messages within. you can say "hey, central server, tel user of id 123456 they have a message from app id: 4321"
[16:37] <Azendale> karni: maybe opensource like launchpad, where there is one official instance, but we can see the code and propose fixes/changes
[16:37] <karni> Azendale: the app receives a push from the server, *THEN* talks to YOUR server to pull the message content
[16:37] <karni> Azendale: Yes, I understant your question. What I mean is, beyond number of push notifications sent, you have a way to avoid any privacy concerns.
[16:38] <larsu> rickspencer3: no... you really want silent sms waking up the client side service so that you can go into lower power modes...
[16:38] <rickspencer3> larsu, sure, whatever the right service is
[16:38] <Azendale> karni: makes sense
[16:47] <larsu> if this is implemented as a dbus-protocal, how are applications woken up when they're not running when a notification arrives?
[16:47] <larsu> *protocol
[16:47] <karni> tvoss_: mind muting yourself?
[16:47] <karni> you're switching when typing
[16:49] <bfiller> QUESTION: can the notifications be delivered to the system for generic notifications in addition to being delivered the app? app might not actually need to know about it right away as long as user is notified
[16:49] <bfiller> i.e. a snap decision displayed by the system, which the user can act further on a launch the appropriate app
[16:51] <karni> bfiller: I doubt. Each push notification is specific to _some_ application, based on the app registration id. However, you could handle a notification by posting a notification (I would imagine).
[16:51] <karni> That's a bit of a wild guess, though. Maybe the attendies will adress your question.
[16:51] <bfiller> kami: sure, but seems overkill to wake the app up if it's something as simple as a notification without further action
[16:53] <karni> bfiller: That is correct, but our server doesn't know that. Perhaps the app server could decide it no longer makes sense to send the notification. OR (I need to read up the doc) we could have a timeout for push messages, so that if you decide it no longer makes sense to send it after an hour (say, live news updates), it would not be delivered at all.
[16:53] <kenvandine> lool, the system settings first run wizard could handle the registration
[16:54] <karni> bfiller: I also think it depends on the ubuntu sdk/api that we will get, because perhaps not the whole app will need to get initialized to make such decision ("should I start? or not.")
[16:55] <lool> kenvandine: good idea
[16:55] <bfiller> karni: could be part of the registration api, the app passes in whether or not it wants to be waken on an incoming notification or let system handle it
[16:55] <karni> bfiller: I think that would miss the point. If you don't want to be waken up for all push notifications, just query a REST api once you start. No?
[16:56] <karni> bfiller: also, you can update your user data (query feeds, messages, whatever) in the background, and once the user launches your app, you're already up to date. how awesome is that :)
[16:56] <bfiller> karni: no I mean say you have a messaging app, and someone sends you a message, you just want to see the message show up as a notify-osd or in the messaging menu. not necessilary launch the app
[16:57] <bfiller> karni: just like sms notifications occur today
[16:57] <karni> bfiller: right. I still think that would need to be handled by the app itself (and post a notification, for instance).
[16:57] <karni> bfiller: I think at this stage of development it would be a too-fancy feature to have :) Possibly in the future? :)
[16:58] <bfiller> karni: yeah I guess, app would need to know about it but not necessarily need to request foreground
[16:58] <dbarth> lool: don't forget about html5 as well
[16:59] <karni> bfiller: yep
[16:59] <dbarth> lool: webapps if your prefer
[16:59] <karni> dbarth: webapps (running in a web view) can still handle push from QML wrapping it
[16:59] <dbarth> lool: cause we'll need to integrate with push notifications to get twitter messages in real time
[16:59] <dbarth> karni: right
[16:59] <karni> lool: ↑
[16:59] <dbarth> but that's a key elemnt for us
[17:00] <dbarth> we'll get it with qt sure
[17:00]  * karni nod
[17:00] <dbarth> or the sdk
[17:43] <Chipaca> bfiller: karni: the "not launch the app" thing is what's called "message interception" in the doc
[17:44] <Chipaca> Azendale: there will be a floss server, and you will be able to point a phone at it (for testing)
[17:44] <karni> Chipaca: perfect, still haven't finished reading it. bfiller, sorry for the confusion.
[17:45] <Azendale> Chipaca: Awesome
[17:48] <bfiller> Chipaca: thanks
[17:56] <dholbach> https://plus.google.com/hangouts/_/7ecpjmkt1j1dfisa4c0fvojhmg?authuser=0 for those of you who want to join in in 3-4m
[17:59] <popey> https://plus.google.com/hangouts/_/7acpikk4fa1i993c57cf7t1mj0?
[17:59] <popey> wat
[17:59] <popey> dholbach: I'm doing app-dev 2
[17:59] <dholbach> popey, I'm sorry - I asked in #ubuntu-community-team and I had set up the blueprint, so I thought I'd do it
[18:00] <dholbach> popey, but if you want to run the session and you updated summit.....
[18:00] <popey> ok, you do it
[18:00] <popey> nope
[18:00] <dholbach> ok
[18:00] <dholbach> popey, https://plus.google.com/hangouts/_/7ecpjmkt1j1dfisa4c0fvojhmg if you want to join in
[18:00] <popey> but you need to re-edit the thing on summit as I trashed the youtube urls
[18:00] <dholbach> oh ok
[18:01] <popey> sorry for trashing them, dpm said I'd be on appdev-2 all day, but happy for you to do this session ☻
[18:01] <robotfuel> does anyone in irc want to join the hangout?
[18:02] <dholbach> popey, no worries
[18:03] <zyga> hi
[18:03] <karni> yo
[18:04] <bregma> which is the correct URL to join?
[18:04] <dholbach> bregma, zyga, karni: want to join?
[18:04] <zyga> roadmr: join the fishbowl
[18:04] <dholbach> https://plus.google.com/hangouts/_/7ecpjmkt1j1dfisa4c0fvojhmg
[18:04] <zyga> dholbach: I'm a bit tired but if roadmr doesn't want to I can
[18:04] <dholbach> as you like it :)
[18:04] <zyga> roadmr: ?
[18:05] <roadmr> zyga: I'm in the bowl
[18:05] <zyga> roadmr: thanks the video was lagging
[18:06] <iBelieve> dholbach: what's the hangouts link? I missed it.
[18:06] <dholbach> iBelieve, https://plus.google.com/hangouts/_/7ecpjmkt1j1dfisa4c0fvojhmg
[18:07] <iBelieve> dholbach:thanks
[18:09] <dholbach> taking notes here: http://pad.ubuntu.com/uds-1311-appdev-1311-desktop-usability-issues
[18:09]  * karni should have probably provided my initial experience as well ;) but we'll get there
[18:16] <dholbach> bregma, you said you had some notes already... would you mind sharing them? (added a work item for it already :-))
[18:18] <bregma> some initial note are at https://docs.google.com/a/canonical.com/document/d/1OvTlzChKhk3374lqAI9j2DRD1fMtyWJLzOGV99_dbTc
[18:22] <dholbach> thanks bregma
[18:22] <dholbach> grrrr, the pad is constantly reconnecting
[18:22] <karni> pad is giving up on me
[18:22] <iBelieve> Does anyone know if someone under 18 can join? Nothing in the agreements I had to agree to said anything, but I remember another young Ubuntu member writing about about it.
[18:25] <karni> iBelieve: what do you mean.. ?
[18:25] <iBelieve> karni: does Google require that users be over 18 to join?
[18:26] <bfiller> dholbach: most of the system apps already run on the desktop, but with the issues you guys mentioned
[18:26] <karni> iBelieve: to join the hangout? I know nothing about that honestly, I'm sorry.
[18:26] <dholbach> bfiller, brilliant
[18:26] <iBelieve> karni: None of the agreements mentioned anything, but look at this post: http://smartboyhwubuntu.wordpress.com/2013/08/27/google-please-let-me-join-vuds/
[18:27] <bfiller> dholbach: gallery, notepad, mediaplayer, camera, browser are all candidates/targets for 14.04 to run better on desktop
[18:27] <karni> #ubuntu-community-team
[18:28] <robotfuel> 'desktop' and  'sdk-app-desktop-integration' are the tags used in bugs for the sdk @ bugs.launchpad.net/ubuntu-ui-toolkit
[18:28] <karni> pad is very much no longer functional. 503
[18:29] <iBelieve> karni, dholbach: thanks for the link and help.
[18:29] <dholbach> robotfuel, do you know which tag is used for which?
[18:30] <karni> aye qtcreator-plugin-ubuntu
[18:31]  * karni thinks what to bring up
[18:33] <iBelieve> QUESTION: will right clicks on the desktop be equivalent to long-presses? I've often wanted this feature.
[18:33] <iBelieve> dholbach: ^^^ has that been discussed at all?
[18:33] <popey> pad is back
[18:34] <dholbach> iBelieve, I have no idea and we're sort of all consumers of the SDK/UI here, so we don't know either
[18:34] <dholbach> iBelieve, this session is mostly about doing research to find out which issues we currently see
[18:35] <bregma> iBelieve, at this point we're still identifying interaction deficits, designers still have to respond on how to address them
[18:35] <karni> iBelieve: I like your idea. However, we're focusing more on issues than features in this session. But I'll be happy to bring it up in the future talks.
[18:35] <bfiller> dholbach: looks like there is another session about this topic on thursday (utc 15:00) . maybe we could get design and sdk team to participate in that session and review the current list you guys have identified?
[18:36] <bregma> bfiller, +1
[18:36] <karni> bfiller: great idea
[18:38] <dholbach> bfiller, awesome, that'd be a good start and short-circuit some of the discussion already
[18:39] <dholbach> bfiller, that's "make click apps runnable from unity7 dash"?
[18:39] <bfiller> dholbach: no, this one http://summit.ubuntu.com/uds-1311/meeting/22075/appdev-1311-apps-convergence/
[18:40] <dholbach> sorry, was looking at the wrong place
[18:40] <bfiller> dholbach: and blueprint here: https://blueprints.launchpad.net/ubuntu/+spec/appdev-1311-apps-convergence
[18:50] <karni> great
[18:54] <karni> dholbach: That was a good session.
[18:54] <karni> Great atmosphere, good notes.
[18:54] <dholbach> lots of experts
[18:54] <dholbach> so yeah - thanks everyone :)
[18:54] <karni> Thanks all :)
[19:02] <dholbach> does anyone want to join in on the session? https://plus.google.com/hangouts/_/7acpjs8c7j7bmbi47an0mbfbik?
[19:03] <dholbach> alecu, ralsina_: you guys? :)
[19:03] <dholbach> cjwatson, are you here for this session?
[19:03] <ralsina_> dholbach: omw
[19:05] <dholbach> anyone else who wants to join in?
[19:05] <ralsina_> alecu: come on in!
[19:05] <cjwatson> dholbach: coming
[19:10] <dholbach> notes here: http://pad.ubuntu.com/uds-1311-click-software-store-status-and-future-development
[19:12] <dobey> beuno, alecu: that would be in the updates app no?
[19:13] <alecu> dobey: or on the details preview after we add the "apps needing update" category
[19:21] <mmcc> I saw a nice explanation a while back of how to handle sorting by review rating in the presence of few ratings: http://www.evanmiller.org/how-not-to-sort-by-average-rating.html
[19:21] <ralsina_> mmcc cool :-)
[19:22] <mmcc> it's a brief and pretty understandable article. seems like a nice solution that's obviously better than simple sort
[19:24] <dholbach> ncie
[19:25] <micah2> QUESTION: Are there plans to support hybrid devices (like the Lenovo Yoga) that sometimes have a functioning keyboard and sometimes don't? When searching for apps on such a device, would both desktop and tablet apps appear?
[19:27] <dobey> micah2: the point of convergence is that there is no difference between a phone/tablet/desktop app. the difference is how the app is displayed on the device. the devices should work with touch and a keyboard both, just fine
[19:28] <dobey> tablets and phones can sometimes have keyboards too
[19:28] <ralsina_> dobey: hold tight to that Pre :-)
[19:28] <dobey> my Pre isn't going anywhere
[19:28] <dobey> but it is completely irrelevant to the question :)
[19:28] <micah2> dobey: Right. I just want to call attention to cases where someone on a lenovo yoga is looking for software, they should be able to install GIMP when in tablet mode, not necessarily use it, but see it in the software center.
[19:29] <juancarlospaco> hello
[19:29] <juancarlospaco> test
[19:29] <dobey> micah2: this isn't about software-center and .debs; it's about click apps which are only converged apps :)
[19:29] <kiwinote> (mmcc: it's worth noting however that until you have enough ratings per app, care should be taken in emphasizing 'top rated' apps too much - the more you focus on top rated apps the more app developers manipulate the system to gain better ratings (and yes this already happens to some extent in the existing app store))
[19:29] <alecu> hola juancarlospaco!
[19:29] <juancarlospaco> the iframe on the page of the streaming is not loading hehe
[19:29] <ralsina_> I am lagged!
[19:30] <micah2> dobey: okay, sorry for making it more confusing than it needs to be, just something on my mind.
[19:30] <juancarlospaco> I was to ask about binary deltas , but already done
[19:31] <juancarlospaco> chromium and foresight linux got that working since years, but its not easy
[19:33] <cjwatson> we can pretty easily repurpose debdelta, which has support for various delta backends etc. and basically seems to be the right design for us
[19:33] <dobey> it's not particularly hard to do it the way solaris, foresight, suse, etc… did it
[19:33] <cjwatson> just wasn't time to do it for 13.10
[19:36] <asomething> has there been any thought about GPL compliance for app that ship compiled code licensed GPL? do we need provide a easy way to get a the source?
[19:39] <juancarlospaco> conary was written on python it seems, the binary delta based package manager
[19:40] <juancarlospaco> this is off topic, but theres a planned way to test apps on Mir on headless ?, ala xvfb
[19:40] <dobey> juancarlospaco: and RPM isn't python, nor is the package manager i wrote, nor is the solaris one
[19:40] <cjwatson> we're not going to switch to a new package manager :)
[19:40] <juancarlospaco> True
[19:40] <dobey> and it is not hard to do with dpkg either
[19:40] <cjwatson> juancarlospaco: there's emulator work in progress
[19:41] <juancarlospaco> Cool
[19:42] <dobey> or just test with the x display backend in qt instead?
[19:42] <dholbach> bah, and it was the last session of the day - I was just getting warmed up!
[19:42] <dobey> it's headless, so it's not like you actually need to test how mir deals with the hardware, for your own app
[19:43] <dobey> dholbach: get mark to join all your sessions so more people will want to join the hangouts :)
[19:43] <dholbach> dobey, haha :)
[19:43] <juancarlospaco> for test as in unitary test, or selenium api like tests
[19:43] <dobey> juancarlospaco: right. but i don't think the display backend should matter, as long as you can run the tests
[19:44] <dobey> several things are running autopilot tests with xvfb already, for example
[19:44] <juancarlospaco> selenium api is 3wc standard, theres a draft for it  :P  it scalated quickly, i suppose you can go phantomjs
[19:44] <juancarlospaco> True
[19:45] <dobey> right, but selenium has nothing to do with mir
[19:45] <dobey> it's just an API for driving web apps for testing
[19:45] <juancarlospaco> ok, thanks, got to go  :)