Places/StatusMeetings/2006-10-12

« previous week | index | next week »

Places meeting: 2006-10-12 4pm PST

sspitzer       dietrich / v_thunder:  should we start?
dietrich       yep!
dietrich       i don't have anything tangible to report yet
dietrich       i've been working on fleshing out the requirements and scenarios for sync
dietrich       and other integration methods
dietrich       i'll try to blog w/ more details soon
sspitzer       I have been going through the code, figuring out what pieces of MOZ_PLACES are bookmarks related, and turning them off with MOZ_PLACES_BOOKMARKS and keeping the history stuff as MOZ_PLACES
sspitzer       so that if you build with MOZ_PLACES you'd get history only.
sspitzer       I'm still working on that.
sspitzer       about blogging, I think it would be good to blog about what we're doing, just so interested observers can find out.
sspitzer       mconnor has suggested this, and so I've set up a blog for myself at blogs.mozilla.com.  will you be blogging there, or on your personal blog?
dietrich       http://dietrich.ganx4.com/
sherman        That would be good.
sspitzer       ok, cool.  any objection to me linking that off the places wiki page, for under the "Team" section?
dietrich       nope
sherman        nope
dietrich       sspitzer: is there a bug for the build-fu parts you're working on?
sherman        speaking of places wiki...
sherman        should it be cleaned up?
sspitzer       sherman: probably, are you thinking of something in particular?
sspitzer       dietrich:  I'll log a bug, and make it block the meta history bug.
dietrich       sherman: yes, i made a few minor updates to the main page, but we'll need to update it as we make design/api changes
sspitzer       dietrich: and attach my patch there, when it is ready for primetime.
dietrich       sherman: afaict, the only major problem with the current wiki docs is that some of the pages are not yet written
dietrich       but the docs there *seem* to correspond w/ the current state of the code
dietrich       sherman: one thing i would like to do at some point, and maybe you can help with it:
dietrich       as we develop the Fx3 feature list, figure out which items are places related
dietrich       so we can take those into account in our design discussions
dietrich       sspitzer: once the build options are in place, i'll be glad to go in and turn off bookmarks code
dietrich       if you have a WIP patch, feel free to send it over
sspitzer       dietrich:  my patch, once completed, should mean that when you build with --enable-places, you'll get 2.0 bookmarks ui and places history UI.  
dietrich       ah ok
sspitzer       when I have a WIP patch, I'll attach to the bug
sspitzer       what were you thinking?
sspitzer       turning of BM code within places backend?
sspitzer       or did I misunderstand?
dietrich       if turning off BM code was a grueling task, that if you had the build options set up, i'd help out there
dietrich       but it sounds like that's not the case?
sspitzer       so far not the case.  (what is slowing me down is some 1.5.0.8 distractions.)
sspitzer       but that is out of the way now.
sspitzer       dietrich:  is now an OK time to chat about the "moz_anno" thing?
sspitzer       or should that be in a blog or newsgroup?
dietrich       sure
sspitzer       actually, before we start that, I had another topic, which was:  the big picture goal for places.
dietrich       i think here is fine, the log goes on the wiki, which is probably enough
dietrich       sspitzer: i.e. beyond getting 2.0 front-end on places backend?
sspitzer       exactly
sspitzer       is that our Fx 3 goal?  or the first milestone for Fx 3?
sspitzer       from http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/bc2c4214179d651e/c55ad92dec30e195#c55ad92dec30e195
sspitzer       I listed our initial goals as:
sspitzer       * ensure that we have the right APIs, data model, and architecture to
sspitzer       allow for synchronization, remote bookmarks and future work in both core
sspitzer       Firefox and add-ons (such as Google's Browser Sync, Foxmarks as well as
sspitzer       add-ons that integrate with social bookmarking services, such as
sspitzer       del.icio.us)
sspitzer       * implement the FF2 UI on top the Places backend, starting with the
sspitzer       History UI [1]
sspitzer       * write some functional and performance tests that can be integrated
sspitzer       into "make check" and into Tinderbox 
sherman        Should we be making an distinction between *initial* goals and *release* goals?
dietrich       sherman: yes definitely
dietrich       sspitzer: yeah, those sound like good first milestone (whenever that is)
sherman        Also looking at the goals outlined on the wiki page... http://wiki.mozilla.org/Places
sspitzer       release goals, for Fx3, and beyond. 
sspitzer       I think those are good starting points, but what about our ultimate goal?  Sort of a places (bookmarks/history/more = tags) roadmap is what I was thinking.
dietrich       but the release goals will likely be guided by the results of the fx3 product dev thats ramping up
dietrich       eg: http://wiki.mozilla.org/Firefox/Feature_Brainstorming
dietrich       We should make sure that whatever goals we have, outside of that list, get added
sherman        An interesting discussion might center around whether or not the places backend could be repurposed for different types of content.
sherman        i.e. hCards, hCalendars, hReviews, etc.
dietrich       then we'd have to rename "places" to "places n' stuff"
dietrich       ;)
sherman        Perhaps!
dietrich       i'd like to have an extensible data model so that moving forward we don't have to keep creating silo code for each "next big thing"
dietrich       however, that's the trap of RDF
dietrich       the kitchen sink
dietrich       i'm sure i can convert any of those formats into sets of triples ;)
sspitzer       triplets!
sspitzer       about the extesible data model, this is what I was getting at with moz_anno.  as we discussed privately, I'd like there to be an easy way to add arbitrary data (and then search on it.)
dietrich       sspitzer: per bookmark?
dietrich       right now, annotations are URI-centric IIRC
sherman        Batch anno would be cool.
sherman        Don't know how mainstream it would be however... sorry, thinking aloud.
dietrich       sherman: what do you mean by batch?
dietrich       sspitzer: i mention that because the scenarios you brought up were about bookmarks, IIRC
sherman        In bookmarks manager, I don't have the ability to select multiple bookmarks and attach a keyword to them.
dietrich       but i guess the places data model does blur the distinction :)
dietrich       sherman: ah, right
sherman        I guess the place where I make the most annotations is in iTunes.
dietrich       like the any music metadata editor can do
dietrich       right
sherman        I download a lot of live music which forces me to do batch annos, the UI is pretty good.
dietrich       sherman: yeah, i totally agree, it's a required feature for music
dietrich       do any of the web 2.0 social bookmarking services have that feature?
sherman        I think what's cool about the social bookmarking services is tag suggest.
sherman        So based upon the URL that I'm bookmarking, what did everyone else use as a tag?
sspitzer       what I was getting at was the ability, for add on developers and ourselves, to annotate items.  I'm not limiting it to just a bookmark.  I'm waving my hand here, but I could see a history add on that would want to annotate history items, and not with a limited set of annotations, but with arbitrary annotations.
sherman        Don't know about batch tag... let me check del.icio.us...
sherman        I agree.
dietrich       sspitzer: right - arbitrary annotations provide a level extensibility that add-on developers could *really* take to the next level
dietrich       however, to some extent, RDF provides that same level of flexibility
dietrich       but falls down flat on ease-of-use for developers
sspitzer       right, but does our current (places) data model / api provide it?
sspitzer       yes, exactly:  ease-of-use!
sherman        Hey, cool... del.icio.us deleted all of my bookmarks and tags!  Nice!
sherman        There's a feature for you... data loss.
dietrich       regarding the annotations data model - it's designed for a limited set of annotation "types" or "names"
myk            sspitzer: i think it does
myk            sspitzer: specifically, i think moz_anno annotates history items, whether those items are bookmarked or not
myk            sspitzer: but you should check with others (or the code) to be sure, since i'm basing this on what it looked like was happening the last time i looked at the database schema, which was a while ago
myk            two specific limitations of the annotation service that i ran into while building support for microsummaries in Places:
myk            1. you can't specify that an annotation should expire when a bookmark is deleted
myk            2. you can't store arbitrary binary data in an annotation, only images
brettw         sspitzer: what you described is what the annotation service does
brettw         myk: what do you mean about point 2?
brettw         There is no special code to handle images
brettw         it supports arbitrary binary data
myk            brettw: perhaps i misunderstood then
brettw         WRT point 1: expiration was not implemented, bookmark level deletion is probably a requirement
brettw         but we never got around to that
myk            brettw: at one point, when i looked at it, it looked like i could only store binary data if it was an image
brettw         nope
brettw         that's probably what the examples were of, but you can put anything in there
brettw         including text/html
brettw         You can put a hole web page in there and load it in a content area
brettw         s/hole/whole
sspitzer       very cool
brettw         sspitzer: to clarify, the annotation service annotations any URI, not just bookmarks
brettw         we have special URIs for bookmark folders so random crap can be attached to those
brettw         the annotation service was originally designed for thumbnails and favicons
brettw         and spellcheck state
brettw         but it was too slow an not specific enough for the favicons, so that had to go in a separate service
myk            brettw: hmm, not sure what i was looking at; i thought it was API, not examples, but it was a while ago, so i don't remember
brettw         it's possible the first version was like this
sspitzer       I need to play around with the annotation service, clearly.
sspitzer       thanks for the info, brettw.
brettw         the only significant problem with it is the lack of expiration
brettw         that & the favicon service are my favorites :)
dietrich       it seems like some expiration should be handled external to the anno service though
dietrich       like bookmark deletion
myk            dietrich: yeah, bookmark deletion itself shouldn't go through the annotation service, but the annotation service should observe bookmark changes and delete annotations that were added with the stipulation that they should only live as long as the bookmark
brettw         Expiration in places is complicated because there are various dependencies
brettw         for example, the favicon needs to stay in if there is a history page that refers to it, and the history page needs to stay in if a bookmark refers to it
brettw         All places expiration is handled in nsNavHistoryExpire
brettw         (.cpp)
brettw         The bookmark observer thingy sounds good for a certain class of items
brettw         Otherwise, search for "FIXME bug 319455" :)
sspitzer       brettw:  thanks for all those FIXME comments, as I go through the code, they have been helping me out.
brettw         it only takes 644 lines to expire things!
brettw         places history expiration happens incrementally as you browse (instead of delaying shutdown)
brettw         and is highly optimized not to delay things, hence the lots o' code
sspitzer       here's are my take away / todo items from our second meeting:
sspitzer       post this irc log
sspitzer       link to blogs from the team list (brettw, myk, sherman, do you guys have blogs and/or want to be listed?)
brettw         not I
sherman        Not yet.
sspitzer       start a thread about the long term goals of places n stuff, starting from the goals listed on the :Places page.
sspitzer       I'm using place n stuff, per sherman / dietrich's comments above.
myk            sspitzer: probably i shouldn't, either, as i'm not on the places team (although i'm interested in places generally and its integration points with microsummaries specifically, hence my lurking in this channel)
sspitzer       myk:  ok
sspitzer       sherman asked about cleaning up of the wiki in general, but are there specifc pages?
sspitzer       the bug where I'll be putting the build patch (per my comment above) is https://bugzilla.mozilla.org/show_bug.cgi?id=356487
sspitzer       thanks again to brettw for providing answers and info about moz_anno
sspitzer       and the rest of places.
sherman        http://wiki.mozilla.org/Bookmarks_Use_Cases
sherman        Seems to be a brainstorming list... perhaps a few other pages.
sherman        I could take a look.
brettw         I'm scared of that page
sspitzer       I'm all out of topics today, anyone else?
dietrich       i think we're done for today
dietrich       thanks again brettw for hanging out and clarifying stuff as we get deeper into places
sspitzer       fwiw, v_thunder was unable to attend due to his machine is dead.
sspitzer       yes, thanks again brettw
sspitzer       I'll go post the log, thanks guys