[15:07] cjohnston, mhall119, I don't suppose you're around? :) [15:08] nope [15:08] * aquarius laughs [15:08] got a few minutes? [15:08] sure [15:09] firstly, your thoughts on https://code.launchpad.net/~sil/summit/more-mobile-summit/+merge/90608 invited [15:09] more importantly, I'm thinking about how to do offline-capable summit [15:09] and I'd like to kick the ideas around a bit [15:10] probably a better discussion with mhall119, but I'll talk.. nigelb you around? [15:11] gimme 30 mins? I'm headed for dinner [15:11] OK. My plan is this: the daily pages (and only those) will be cached. When you visit one of the daily pages, it's loaded from the cache and the top of the page says "Schedule saved 1h43m ago". If, and only if, you are online *and* the schedule has been updated since then, that will also say "Schedule has been updated: [load new schedule]" [15:12] that'd be cool [15:13] the issue is: if you're online and you never go offline (you're using a laptop and you're sat at UDS itself during the day), it'll still work like this: that is, you'll have to explicitly hit that [load new schedule] button to get updates, *even if* you refresh the page with F5 [15:13] is that too annoying? [15:13] yes [15:13] to me atleast [15:14] would it be possible to do "if viewed from phone cache and display info, else act normal" [15:14] ? [15:14] aquarius: before I go, can we use localstorage? [15:14] nigelb, we can, if we want to build a separate explicit version of summit that renders everything client-side, and make an API for it to talk to to fetch data. That seems like a lot of work for not much benefit to me [15:15] cjohnston, it is, as long as you can decide "is this a phone" on the *server*. Which is hard -- how will you do it? [15:15] that makes sense. [15:15] I've never done anything with phones, so I have no idea [15:16] you can deetect *specific* phones (say, an iPhone, or Android), but that'll exclude people with blackberrys and windows phone 7 and n9 and so on [15:17] gotcha [15:17] and then people will say: this is typical Ubuntu only caring about apple and google and not my FreedomPhone which is quite capable of enjoying this offline magic but you excluded me anyway because you hate freedom [15:17] and they will say that to you and you will get tired of it :) [15:18] lol [15:32] cjohnston, next question. I'd like to have some sort of identifying string which is "the state of conference UDS-P right now", such that that string will change if anything at all changes about the conference -- a session is rescheduled, a session's title changes, a session is deleted, etc [15:32] where would I get such a thing? [15:33] I could obviously do: for session in all_sessions: longstring += session.title + session.time + session.description; identifying_string = md5(longstring) [15:33] is there an easier way? :) [15:36] aquarius: I don't believe we have anything like that [15:37] and the schedule changes so frequently.. thats why the display monitors refresh every 5 minutes & we added that little "the page was last refreshed [15:37] " [15:38] ya [15:38] people showed up to work on the house, so im only partially here [15:48] no worries [15:48] would be interested in nigelb's thoughts on the caching stuff, too [15:49] aquarius: I like your idea. I had this md5 thoughts a few months back to refresh only if there was a change. [15:50] nigelb, aren't you having lunch? :) [15:50] Dinner. [15:50] I just got back [15:50] yeah, the md5 thing is one way to do it, right enough, but computing it is fairly expensive :( [15:50] which we don't want to do every time anyone requests a page... [15:50] well, we could store the hash into memcached. [15:51] and remove the key when something changes. [15:51] we already do something of this sort. [15:51] oh? [15:51] render.py had something of this sort. Listening for changes is already there. [15:51] problem with that approach is that it requires poking everything that writes to the DB to remove the cache [15:51] Well, poking everything that matters. [15:52] I'd argue only the sessions need poking. [15:52] if a new person signs up, we don't need to update. [15:54] agreed [15:54] well... it might be *you* :) [15:55] Let me take a look tomorrow morning :) [15:55] but poking the DB writing stuff is a big faff that I'd like to avoid ;) [15:55] I haven't touched summit in a while due to lack of time. I'll try to make time for this. [15:57] is there a DB revision somewhere? [15:57] can't remember whether django maintains that :) [15:58] well, you can do ./manage.py migrate to migrate all the changes we've made. [15:58] ah, no, not that sort of revision. I mean, one number somewhere which django increments every time the DB changes :) [15:59] Nope [16:00] this is when data changes right? [16:00] yeah [16:00] I thought that was a bit hopeful :) [16:01] heh [16:05] nigelb: fwiw, there is one bug that needs to be fixed prior to looking at the offline stuff please... it needs to be fixed in the next couple days [16:05] prior to connect [16:05] aquarius: are you on and android? [16:05] I'm not touching anything critical and time-bound. [16:06] I am [16:06] I know I won't finish it. [16:06] cjohnston, having someone with an iphone test my mobile branches would be a good idea ;) [16:06] i have access to one [16:06] aquarius: download this: https://market.android.com/details?id=org.linaro.connect&feature=search_result#?t=W251bGwsMSwyLDEsIm9yZy5saW5hcm8uY29ubmVjdCJd [16:06] im going to attempt to make one for ubuntu prior to uds [16:07] ah, OK. My intention with the mobile patches is to make it so you don't *need* a native app :) [16:07] ya.. [16:07] and then we support all phones without having to make fifty different mobile apps ;) [16:07] i know.. but that's kinda cool too [17:58] aquarius: your branch is merged [17:58] http://91.189.93.80:8000/uds-p/ [17:59] I'd think maybe remove the topnav (login, ubuntu.com, community, support, partners) [18:40] hey, cjohnston, sorry was afk [18:41] I kept those bits on the summary pages just in case someone needs them (although they are reformatted a bit on narrow screens) [18:42] ok [18:42] easy to remove if you think so -- they're removed on the daily pages, because those ones are specificallymobile-optimised [18:42] I just think those links are way too small.. I could be wrong, but i dont see anyone clicking partners on their cell phon [18:42] e [18:42] I'm ok with the orange bar.. im talking the white bar above it [18:43] the earlier pages aren't really designed for mobile -- all I've done is made them a bit more sensible on a mobile :0 [18:43] so they don't start off zoomed out, etc [18:43] right [18:43] and I kept log in 'cos... people need to log in ;) I've reformatted that on the daily page (and turned off the rest of that white bar) [18:44] theres a login link lower, below the summit info [18:44] lets get feedback from nigelb and mhall119 [18:46] sure -- that's why I proposed a merge, so you guys can decide whether you like it or not ;) [18:46] :-) [18:46] I'm off for a bit.. if you need something just poke and ill help when i get back [18:47] no worries. I have totally failed to do any hacking today anyway :) [18:47] lol [18:48] we need to figure out this schedule display issue... and i dont have time to think about it