| *** openstack has joined #storyboard | 08:55 | |
| *** openstackstatus has joined #storyboard | 08:57 | |
| *** ChanServ sets mode: +v openstackstatus | 08:57 | |
| *** openstack has joined #storyboard | 09:10 | |
| *** openstackstatus has joined #storyboard | 09:12 | |
| *** ChanServ sets mode: +v openstackstatus | 09:12 | |
| *** openstackgerrit has joined #storyboard | 09:15 | |
| *** krotscheck has quit IRC | 09:20 | |
| *** MaxV has joined #storyboard | 09:21 | |
| *** krotscheck has joined #storyboard | 09:23 | |
| *** MaxV has quit IRC | 09:23 | |
| *** MaxV has joined #storyboard | 09:28 | |
| *** openstackgerrit has quit IRC | 09:34 | |
| *** jedimike has joined #storyboard | 09:34 | |
| *** openstackgerrit has joined #storyboard | 09:35 | |
| *** cody-somerville has quit IRC | 10:02 | |
| *** MaxV has quit IRC | 10:39 | |
| *** openstackgerrit has quit IRC | 11:47 | |
| *** MaxV has joined #storyboard | 12:33 | |
| *** MaxV_ has joined #storyboard | 12:47 | |
| *** MaxV has quit IRC | 12:49 | |
| krotscheck | jedimike: I just talked with a UI Architect from IBM. Consensus was that the ability to determine position within a result set is important, and the implementation of page/limit vs. marker/limit is an implementation detail. | 12:51 |
|---|---|---|
| *** MaxV_ has quit IRC | 12:52 | |
| krotscheck | jedimike: So we _could_ use marker/limit, assuming that the actual position in the first record in the result set is included. Or we could infer the position from the page if we reimplement as page/limit. | 12:52 |
| krotscheck | jedimike: Or, to greatly simplify things, we can do offset/limit and get all the data from there. | 12:53 |
| krotscheck | I’m leaning towards the latter, because it gives us the most UI options with the smallest API footprint. | 12:53 |
| jedimike | krotscheck, yeah, I agree. I was thinking about edge cases earlier, and if you edit the last record on a page and alter data that the result set is ordered by, returning to the list could put you on a totally different page, with no way of skipping back to where you were | 12:53 |
| krotscheck | jedimike: Right, that too. | 12:54 |
| krotscheck | Honestly, there’s no good options. | 12:54 |
| krotscheck | Because there are edge cases that will invalidate all the things. | 12:54 |
| jedimike | all depends what we care about most, user experience or server load | 12:54 |
| jedimike | btw, I find Horizon absolutely horrible to use because of the limitations of marker/limit | 12:55 |
| krotscheck | Yeah, we spent a good amount of time complaining about that :) | 12:56 |
| jedimike | haha :) | 12:56 |
| krotscheck | I kindof feel that marker limit is just plain a Bad Idea (TM) because it doesn’t inherently provide a way to get the position in a result set. | 12:57 |
| jedimike | I agree, without tracking your position, as soon as you order by anything but updated/created, you've no way of knowing if you've missed data | 12:58 |
| jedimike | for people who absolutely have to care about all aspects, you end up having to snapshot the results in a temporary table and monitor for any changes... gets a bit heavy on the server (although the snapshots are easily shardable) and you have to present notifications to the user that new data is available etc.... | 13:01 |
| krotscheck | NikitaKonovalov: I’m renaming our etherpad to match the naming convention for the summit. kilo-infra-storyboard | 13:02 |
| jedimike | for storyboard, I don't think we care *that* much :) | 13:02 |
| krotscheck | jedimike: So, I think we care. | 13:02 |
| krotscheck | jedimike: And the reason has nothing to do with functionality | 13:02 |
| krotscheck | jedimike: The reason is that everyone will be using StoryBoard, and sooner or later they’re going to say: “Hey why don’t we do what StoryBoard does?” | 13:02 |
| krotscheck | jedimike: And when that happens we need to make sure that what we have isn’t going to be a horribly bad idea. | 13:03 |
| jedimike | krotscheck, ok, so would you like me to write up the approaches I've used in the past for people who could lose 5-50k if they don't get notified of all data changes or miss results? | 13:04 |
| krotscheck | jedimike: I think so. Does it include a web worker cache that abstracts away a long-running synchronization thread? | 13:05 |
| krotscheck | jedimike: What’s your last name? | 13:07 |
| krotscheck | /whois is not telling me and I’m too lazy to google | 13:07 |
| jedimike | krotscheck, it can do, if we care enough to notify users of new or changed data without any interaction from them. Heh, it's Heald :) | 13:08 |
| krotscheck | Thanks :) | 13:08 |
| jedimike | yeah, so markers are great and work well, until you want to sort your results. Then they're no good if you care about users having a good experience and seeing all their data | 13:09 |
| jedimike | i smell a lightning talk at the next summit ;) | 13:10 |
| *** MaxV has joined #storyboard | 13:14 | |
| *** jedimike is now known as jedimike|lunch | 13:23 | |
| *** MaxV has quit IRC | 13:53 | |
| krotscheck | jedimike|lunch: I’m in the horizon session, and it sounds like they’re fixing their paging as well. More details in a bit. | 13:58 |
| jedimike|lunch | krotscheck, awesome :) looking forward to the highlights! | 13:59 |
| krotscheck | Hrm. Actually, it looks like they want to kill pagination altogether, because some of their upstream API’s don’t support it (LDAP for instance) | 14:01 |
| jedimike|lunch | so are they planning on delivering the whole dataset to the browser and paging it client side? that's certainly one option, if you have a web worker to pick up updates and notify the user of them | 14:02 |
| *** miqui has joined #storyboard | 14:13 | |
| *** jedimike|lunch is now known as jedimike | 14:19 | |
| krotscheck | jedimike: I… it sounds like they’re going to filter server side (horizon) rather than server-delegated-api side ( horizon -> nova). | 14:20 |
| krotscheck | And no paging. | 14:20 |
| jedimike | wow | 14:21 |
| *** MaxV has joined #storyboard | 14:29 | |
| *** MaxV has quit IRC | 14:29 | |
| *** jtomasek has joined #storyboard | 14:36 | |
| *** jtomasek has quit IRC | 14:43 | |
| *** MaxV has joined #storyboard | 14:55 | |
| *** MaxV has quit IRC | 14:55 | |
| gothicmindfood | krotscheck: you missed a 'storyboard will solve this' joke in the qa-ci session :) | 15:04 |
| gothicmindfood | (unless you're here) | 15:05 |
| *** MaxV has joined #storyboard | 15:29 | |
| *** timrc-afk is now known as timrc | 15:40 | |
| *** MaxV has quit IRC | 16:06 | |
| *** jtomasek has joined #storyboard | 16:11 | |
| *** MaxV has joined #storyboard | 16:16 | |
| krotscheck | I was there :) | 16:16 |
| krotscheck | I think | 16:16 |
| krotscheck | Wait, no. I was at the gate session, not the CI session. | 16:17 |
| *** jtomasek has quit IRC | 16:24 | |
| *** jtomasek has joined #storyboard | 16:40 | |
| *** MaxV has quit IRC | 16:46 | |
| *** mattfarina has joined #storyboard | 18:11 | |
| *** jedimike has quit IRC | 18:17 | |
| *** jtomasek has quit IRC | 18:27 | |
| *** jtomasek has joined #storyboard | 21:18 | |
| *** miqui has quit IRC | 21:46 | |
| *** mattfarina has quit IRC | 22:05 | |
| *** MaxV_ has joined #storyboard | 22:46 | |
| *** MaxV__ has joined #storyboard | 22:49 | |
| *** MaxV_ has quit IRC | 22:51 | |
| *** jtomasek has quit IRC | 22:52 | |
| *** MaxV__ has quit IRC | 22:53 | |
| *** MaxV_ has joined #storyboard | 23:50 | |
| *** MaxV_ has quit IRC | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!