Places/StatusMeetings/2006-10-19
From MozillaWiki
< Places | StatusMeetings
« previous week | index | next week »
Places meeting: 2006-10-19 4pm PST
dietrich i put up some bookmarks recommendations here: http://wiki.mozilla.org/Places:BookmarksComments thunder I skimmed it last night dietrich if anyone has had a chance to look through it, it'd be great to get feedback thunder it looked pretty good overall * thunder opens it up now sspitzer dietrich: I haven't had a chance to read it yet, my apologies. I'll do some reading today and put comment on the discussion page. dietrich some of the changes are sync-related, but stuff like unique IDs for bookmarks seem like a must-have dietrich sspitzer: cool, thx sspitzer I'm also behind on reading dan's perf results thunder dietrich: one thing that did come to mind, though thunder is that "singleton model" doesn't necessarily exclude us from having *non-special-cased* metadata such as titles or anything else thunder that was just one proposal thunder ne could work out a data model in which URIs are unique, but there are multiple other bits of data (e.g., bookmarks) which point to each URI thunder s/^/O/ dietrich hm, that sound like what i said. maybe i'm not understanding :) thunder dietrich: not sure if I'm making sense? dietrich s/sound/sounds/ dietrich so, in the framework i proposed, you'd have this: thunder well, it sounded like, to provide for multiple bookmarks, we'd do away with "the singleton model" entirely sayrer thunder: that makes sense, but then the URI is a JOIN (by reference). not sure that is good for sync dietrich URI1 -> BookmarkURI1 -> title thunder but we'd realistically *want* that, for history dietrich and URI1 -> BookmarkURI2 -> title thunder sayrer: a bookmark URI, you mean? thunder (if so, yes) sayrer yeah, if the bookmarked link over in a history table, that could be bad for sync thunder though it could be made reasonably speedy, perhaps - I don't know thunder oh, not speed concerns. sync. hm sspitzer sayrer: what do you mean by: "if the bookmarked link over in a history table" thunder I don't think I understand thunder the bookmark would be a unique object, but not unique-by-url dietrich thunder: all i proposed really, was another level of indirection between the singletone URI in history, and bookmark properties thunder ah! thunder okay dietrich not to gut the existing places history arch sayrer if the string is somewhere not in the bookmark table, and multiple bookmarks can join on it, that could get hairy I think. that's all thunder then we are pretty much in full agreement thunder sayrer: for e.g. deletion? sayrer yeah. I think people who want to JOIN on bookmarks should do "WHERE bmks.URI == history.URI" thunder (addition is pretty easy) sayrer that is all from me :) thunder right. sspitzer dietrich: so you want to add another level of indirection to solve this problem, what's the new singleton? sspitzer can you give an example that I can wrap my head around? thunder sspitzer: history rows are stil unique by url thunder sspitzer: there is a new bookmarks table where multiple rows can reuse the same history row dietrich sspitzer: a URI for each bookmark dietrich sspitzer: like the example in scrollback thunder well, rather, have their own uri thunder but I think we'd want to also link to the history table where possible dietrich HistURI1 -> BookmkURI1 -> title sayrer someone willing to take an action to draw a strawman table? thunder I can write what I'm thinking more or less in the discussion tab of that page dietrich thunder: yeah, each bookmark would likely have a FK back to the history table thunder I don't know if it's really what dietrich had in mind thunder dietrich: well, not every boomkmark, unfortunately dietrich thunder: yeah please expand on what i have, or explain another approach thunder since it's possible (and I think should continue to be possible) to have a bookmark that points to a place you've never been to thunder which is unfortunate for the data model dietrich thunder: so, the moz_history table is ill-named brettw it should probably be moz_urls or something dietrich yep thunder yeah dietrich sayrer: yes, i'll create a new schema for what i proposed dietrich and put it on the wiki thunder so basically a bookmark has a moz_url_id field, which can be null sayrer sounds good. (I don't like discussion pages, fwiw. people should add and edit each other's text) dietrich sayrer: i'm fine w/ that thunder where null == user has never (as far as history goes) been to that uri brettw why bother with that brettw why not just join on the URI? brettw that sounds like too much extra bookkeeping thunder hm. true. is it as fast? brettw and it makes expiration slower brettw should be fast enough brettw especially since you don't usually do thousands of bookmark operations dietrich thunder: no, a bookmark has a moz_url_id field which can't be null, and there are no entries in moz_historyvisits table for that id sayrer I think we could write pretty naive code and not notice perf on bookmarks stuff dietrich brettw: what sounds like extra bookkeeping? brettw keeping track of the bookmark URL and a separate link to history brettw wait, I changed my mind brettw I agree with dietrich, why not keep it the way it is now brettw ? thunder dietrich: er, which can't be null? what would it be set to when the url is not visited? brettw thunder: currently, it always refers to the history table brettw if it isn't visited, it's still in the history table brettw but has no visit records brettw this way URL storage is centralized thunder okay, sure. thunder hence the rename sspitzer history table == moz_history, which we agree should be renamed to moz_urls? thunder of the table thunder it's really "urls we know about" dietrich sspitzer: yes, i 2nd that sspitzer (I'm just trying to make sure I understand brettw's comment) brettw sspitzer: right brettw even fake URLs like place: URIs thunder er, maybe moz_uris then :) brettw speaking of which, those cause problems dietrich brettw: like what? brettw dietrich: you can set a bookmark folder's favicon using it's canonical place: URI brettw this is great brettw the problem is with expiration brettw there needs to be special logic to link this URI to the bookmark folder brettw so when you delete the folder, the history row is unlocked brettw I guess the bookmarks system should just do this brettw not really a big problem, just a minor bug brettw currently place: URIs never get deleted dietrich brettw: yeah that sounds like bkmk service bookeeping dietrich ah that's good to know about sspitzer brettw: never deleted from moz_history (aka moz_urls)? brettw sspitzer: right brettw there's a bug on that somwehere thunder so, with the current model, deleting history seems like it would be rather slow thunder is it? brettw it's highly optimized brettw so no :) thunder okay :) brettw we do a little at a time, so it never ends up being too much work dietrich anyone else have items to discuss? thunder anyone have any comments on the perf stuff? dietrich thunder: at the fx3 meeting today, someone mentioned a canonical page set for Tp tests dietrich might be useful for testing places perf thunder yeah thunder definitely dietrich i didn't catch the name of who was making it tho thunder I used a zip file that vlad gave me thunder which has stuff like cnn.com, apple.com, slashdot, etc -- from like 6 years ago ;) dietrich haha i think that's the page set we use now thunder yeah sspitzer on my end: I have to do some cleanup, per dietrich, on my patch brettw it's not necessary to worry about the exact contents of pages brettw only the number of links brettw and the number of iframes brettw places doesn't care about anything else thunder brettw: what about the relative percentage of visited/not visited links? brettw thunder: yes, that's true too, but the testing set doesn't affect that brettw and in the general case, only like 2 links are ever visited brettw on average thunder right, we were discussing having multiple testing sets thunder I thought about writing a little script to pull all the urls from the testing set and add them all to the history table sspitzer brettw: where does that general case come from? brettw my ass sspitzer :) thunder a fine location for urls thunder I'm sure sspitzer moz_brettw_ass dietrich places:folder=brett's_ass brettw I believe there are 200 links per page in the PLT on average brettw and for my history the average URL length is 100 bytes brettw but that's because I use gmail :/ brettw for normal people it will be smaller brettw gmail accounts for like 75% of my historyu thunder so, to clarify, you think that the number of history rows more or less eclipses anything else? thunder I guess I'm asking, is it worth spending time creating different test cases where we have a lot of visited links, etc brettw not sure thunder ok thunder I guess it might be worth doing at least once, then brettw I'd look at the numbers I posted on that bug thunder nod sspitzer on my end: I have made some progress with the history sidebar, but I want to finish that MOZ_PLACES_BOOKMARKS patch first, to unblock jminta and others. thunder sspitzer: sounds good sspitzer about the bookmarks UI, I think everyone is ok with starting to re-implement the Fx 2.0 UI on top of what we have now (the places backend) and adjusting as needed. dietrich i have to go afk, back in 5 sspitzer jminta was asking around for 3 - 5 day tasks. sspitzer s/for/for a thunder I have nothing else. half of my time this week has been on something else :-/ sspitzer I'm out of updates as well, as I've been chasing some 1.5.0.8 / Fx20 gremilns for part of the week. sspitzer sayrer has a big patch for livemarks thunder woo gremlins thunder I haven't seen that in ages thunder so, are we done-ish? sayrer sspitzer has a big review for livemarks ;) thunder ha :) sspitzer your patch is in, but needs a second pair of eyeballs, right? sspitzer (sorry for the delay!) sayrer yeah, mconnor and bsmedberg want more eyes sspitzer https://bugzilla.mozilla.org/show_bug.cgi?id=353434 for those playing at home sayrer not that they should be crying for the loss of the old feed parser sayrer the places stuff is a pretty straight port sspitzer so one take away from today was: sspitzer dietrich proposal sspitzer robert asked: someone willing to take an action to draw a strawman table sspitzer I'll ping dietrich to see if he doesn't mind adding that to http://wiki.mozilla.org/Places:BookmarksComments sspitzer the other take away is I owe sayrer a review sspitzer and I need to finish my patch to get some r= from dietrich. sspitzer I'm all out for today. same bat time, same bat channel next week? sspitzer thanks again to brettw (and sayrer) for showing up to these meetings. dietrich yeah thanks everybody dietrich my one request is for people to take a look at my bookmarks recommendations to see if they make sense sspitzer dietrich: will do, sorry for lagging. dietrich so we can make decisions and move forward thunder nod thunder dietrich: will do dietrich feel free to comment in the discussion page, or just edit the page itself
