[13:04] <gary_poster> hey danilos I still have one more part of the pre-imp that I'd particularly like to talk about (because it involves choosing among what I consider non-wonderful options).  You available in five or ten minutes, or maybe after the team call?
[13:05] <danilos> gary_poster, yeah, available now
[13:05] <gary_poster> ok cool will ping in just a few min.  ty
[13:05] <danilos> gary_poster, k
[13:34] <bac> benji: let's talk.  i can push my updates when you're ready
[13:40] <benji> bac: is this the plan: you push ~bac/launchpad/accordionoverlay, I merge from it to fix any conflicts, I push my branch and you merge from it?
[13:41] <bac> benji: or i can push to the shared yellow branch, you merge, and push back to the shared yellow branch.
[13:41] <bac> s/~bac/~yellow/
[13:41] <benji> that sounds good
[13:41] <bac> in your url above
[13:42] <bac> ok, let me do so now.  it still acts funky but it isn't going to get any better.  first, i have to merge in huw's changes.
[13:43] <benji> k
[13:48] <bac> benji: have at lp:~yellow/launchpad/accordionoverlay
[13:48] <benji> thanks
[14:02] <gary_poster> https://pastebin.canonical.com/43866/
[15:23] <benji> ok bac: I had to fix some relatively minor conflicts and do some testing by hand, but lp:/~yellow/launchpad/accordionoverlay/ has been updated
[15:23] <benji> I'm very interested in your thoughts on the structure of the JS I added.
[15:23] <bac> benji: ok
[15:26] <danilos> gary_poster, anyway, my branch is up for review, ready whenever you are
[15:27] <danilos> actually, bb in a minute :)
[15:30] <bac> benji: i'm just scanning through it now and it looks good.
[15:30] <benji> cool
[15:30]  * danilos : back
[15:30] <bac> benji: i found one thing that appears to be a regression, possibly a merge issue
[15:30] <benji> what's that?
[15:30] <bac> / XXX Should this be part of config instead of hard coded?
[15:30] <bac>     add_subscription_overlay.render('#add-subscription-container');
[15:31] <bac> in my branch i was using a config variable for that
[15:31] <bac> i had it so there were no external dependencies on magic names
[15:37] <benji> bac: I've not plumbed the depths there yet, but the original code didn't work, I /think/ it's a difference between the way FormOverlay and PrettyOverlay work.
[15:38] <bac> benji: ok.  your comment is correct, though, and we need to get back to a place where the id comes from the config
[15:38] <benji> yep
[15:38] <bac> your comment in the code, i mean
[15:41] <bac> benji: i'm still fighting the open/close stuff
[15:41] <bac> benji: would you be able to look at actually populating the accordion?
[15:43] <benji> bac: I certainly can.  I wonder about scheduling issues, i.e., Gary seems keen on me starting on the edit functionality because the other line of development needs it too.
[15:44] <bac> benji: just a suggestion for you and gary_poster to decide
[15:45] <gary_poster> I'm fine with either. collaboration +1
[15:49] <benji> gary_poster, bac: I'll work on popultating the accordion widget then.
[15:50] <gary_poster> cool
[17:08] <benji> bac: does this seem like a sane approach? http://pastebin.ubuntu.com/571806/
[17:09] <benji> I'm a little annoyed at duplicating the contents of the importance vocabulary, I guess I could add that data to what's provided when the page loads.
[17:14]  * benji lunches
[18:39] <bac> benji: that is annoying
[18:40] <benji> I'm working on the smuggle-vocabulary-data-from-the-server approach now.  If it works out we can use it for the other bits too.
[18:44] <bac> benji: we might also try including a hidden div on the page and just referencing it
[18:44] <bac> benji: i think the items inside the accordion can just be a node
[18:44] <bac> i'm not sure that's any better than your smuggling, though
[18:45] <benji> yeah, I have a slight preference for moving data from the server to the client instead of HTML; it's an odd sensation for a web app developer ;)
[19:30] <gary_poster> bac, call?
[19:30] <bac> yep
[19:55] <gary_poster> benji, preview question from our call because my curiosity burns, it burns!  Did Huw ever get bac to you about your email about the twisty usage/placement?
[19:55] <gary_poster> eh, sorry Brad :-P.  "back"
[19:55] <benji> gary_poster: I was thinking about that this morning.  Not a peep yet.
[19:56] <gary_poster> :-/
[19:56] <gary_poster> benji, could you retry?  Maybe this time include jml in the CC and see if that changes anything.
[19:56] <benji> I'll write down a to do to ping him again.
[19:56] <gary_poster> thanks
[19:57]  * gary_poster stares at "a to do to" and contemplates the wonder of it all
[20:00] <gary_poster> bac or benji, do you happen to know if we have an existing way to generate a short unique resolvable identifier to arbitrary LP model objects--or at least those that might be a bug target?  The best I can think of is a url, but that's significantly longer than I need--I need, say, an integer or something I can compress to 8 chars or less.
[20:01] <benji> The only think I can think of would be the name and type (e.g., "firefox", "p" (for project)).
[20:02] <gary_poster> benji, yeah, or the id and type, but I assume we don't have an existing type mapping-ish thing
[20:02] <gary_poster> which is kind of the trick :-/
[20:03]  * gary_poster misses that Zope 3 ZODB thing with the integer ids for everything
[20:03] <benji> you could also use URI and a shorthand for the vairous prefixes, p/firefox would expand to https://launchpad.dev//api/devel/firefox
[20:04] <gary_poster> that's an interesting idea.  sort of a traversal-y approach
[20:04] <benji> on a related note, they finally got around to doing an int ID utility that doesn't generate as many conflicts: http://pypi.python.org/pypi/zc.intid/1.0.0
[20:05] <benji> (the IDs are stored in the object instead of in the int ID utility)
[20:05] <benji> gary_poster: where are you doing the generation of IDs and expansion of IDs?
[20:05] <gary_poster> OIC--you remove one of the two big btrees?
[20:07] <benji> exactly
[20:07] <gary_poster> benji, I was thinking I could use just ids and a few types until I realized that targets could be a variety of types, so this was just in, say, bugs/mail and bugs/scripts.  I'm still at the sketching step, sadly
[20:09] <benji> gary_poster: it wouldn't be hard to do a pair of utility "URI shortener/expander" utilities; you could even make them leave the URI alone (and maybe log a warning) if they don't know how to shorten the input
[20:10] <gary_poster> benji, I don't have a picture for how this would work yet--unless you mean it has a new table that maps ids to URIs?
[20:10] <gary_poster> That doesn't seem to be what you mean, which is good, 'cause that seems problematic :-P :-)
[20:11] <benji> I was thinking the mapping would be in code, but you could store it in the DB if that made more sense
[20:11] <benji> oh, no, I meant that the shortener would have a set of *prefixes* it recognized and replaced with one character shortcuts
[20:11] <gary_poster> If you were to create a mapping in code, might it make more sense to map ids to classes?  That's what I was thinking
[20:12] <benji> could be, I'm not entirely clear on what you'll be using the short IDs for
[20:12] <gary_poster> sure
[20:13] <gary_poster> I'll putz around on it and talk to you about it on our call if we have time benji :-)
[20:13] <benji> cool
[20:58] <benji> bac: I just pushed checkbox generation for importances and statuses, using server-side data from the proper enums to generate them; they're not yet saved in the resulting filter object yet though
[20:58] <bac> nice
[20:59] <benji> gary_poster: I'll be ready in a couple of minutes
[21:00] <gary_poster> ack benji, thanks.  I'm listening so just talk on mumble and I'll figure out how to unmute and then say hi. :-)
[21:32] <gary_poster> https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications/Testing/EditingRound2