Places/StatusMeetings/2006-10-19

From MozillaWiki
Jump to: navigation, search

« 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