View source for Places/StatusMeetings/2006-10-19

== 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