[12:49] <leny> Are there any plans to add Maestro or Paypal to the billing options on uo ?
[12:51] <aquarius> leny, I don't know. I'll ask
[12:52] <leny> Thanks I'm sure I'm not the only one who doesn't use _credit_ cards but has a debit card. I'll wait
[12:52] <aquarius> it's on the list of stuff we'd like to do at some future point, but we don't yet have a time when it'll happen, sorry
[12:54] <leny> aquarius, OK, announce it on the twitter etc if/when it happends and you'll have one more customer.  Thanks
[12:54] <aquarius> leny, no problem :)
[15:00] <CardinalFang> Desktop+ MEETING BEGINS.  Say 'me' to claim a slice of the stand-up meeting, then take your turn by saying DONE/TODO/BLOCKED.
[15:00] <teknico> me
[15:00] <jblount> me
[15:00] <CardinalFang> me
[15:01] <urbanape> me
[15:04] <aquarius> me
[15:05] <teknico> rodrigo_, vds?
[15:05] <rodrigo_> me
[15:06] <teknico> I'll start
[15:06] <teknico> DONE: started strengthening net access, started configuring funambol for sending sms messages (#418048), some bug triaging
[15:06] <teknico> TODO: more bug triaging, finish configuring funambol for sending sms messages (#418048), finish strengthening net access
[15:06] <teknico> BLOCK: none
[15:06] <teknico> next: jblount
[15:07] <jblount> DONE: Catchup from holiday, started public links web ui
[15:07] <jblount> TODO: Finish public links web ui, chat with statik about prioritiz/sing stuff for this week
[15:07] <jblount> BLOCKED: Just updated trunk and got bit by #503395
[15:07] <jblount> CardinalFang: YOU!
[15:07] <CardinalFang> DONE: cleaned up local machines.
[15:07] <CardinalFang> TODO: code reviews.  put jobs in bugs or blueprints to placate boss.  fix tomboy subsequent-revision bug in server.
[15:07] <CardinalFang> BLOCKED: None
[15:07] <CardinalFang> urbanape, if you please....
[15:07] <urbanape> DONE: Came up with a simpler, far more brilliant plan with the help of aquarius and thisfred. Started gutting code.
[15:07] <urbanape> TODO: Finish it up, between on-call reviewing.
[15:08] <urbanape> BLOCK: None
[15:08] <urbanape> This is the dawning of the Age of Aquarius! Aquarius! Aquarius!
[15:08] <aquarius> ⚀ DONE: start putting together music store screenshots for review; allow music store widget to correctly log in to website; allow dev server to see live music store; update music store blueprint with work items
[15:08] <aquarius> ⚁ TODO: package rhythmbox plugin; make music store views better; make workitems of outstanding todo items; make tomboy first-sync experience nicer
[15:08] <aquarius> ⚂ BLOCKED:
[15:08] <aquarius> rodrigo ftw
[15:08] <rodrigo_> • DONE: Packaging of libubuntuone. More new XML<->HTML converter work. Music store discussions. More contacts picker work
[15:08] <rodrigo_> • TODO: Conflict resolver tool in pair tool. Look at becoming a MOTU (https://wiki.ubuntu.com/UbuntuDevelopers). Make sandy's snowy test suite work with our server (http://git.gnome.org/cgit/snowy/tree/api/tests.py). Discuss with jdo and aquarius about oauth token per app, not per machine? Add envvar to override music store default location
[15:08] <rodrigo_> • BLOCKED: no
[15:08] <rodrigo_> next vds
[15:08] <aquarius> er, put "package RB plugin" on rodrigo_'s todo :)
[15:08] <rodrigo_> aquarius: yeah
[15:09] <rodrigo_> aquarius: you need to do a release first though
[15:10] <jcastro> hey wait, the rb bits are a plugin? all self contained?
[15:11] <aquarius> jcastro, it's in two halves; a U1MusicStore gtk widget, and a RB plugin which embeds the widget.
[15:11] <jcastro> oh ok, I am just wondering how much surgery will be done to rb itself
[15:11] <aquarius> None. It's a plugin.
[15:12] <aquarius> No hackery in RB core required.
[15:12] <jcastro> right, that makes that mail I sent you guys about talking to rb upstream moot. So, yay!
[15:13] <aquarius> well, kinda; I spoke to RB upstream anyway, with lots of "I want to do X. How do I do it?" questions, but they were very helpful :)
[15:13]  * jcastro nods
[15:13] <jcastro> you two make my job very easy
[15:15] <aquarius> I try :)
[15:15] <aquarius> vds?
[15:16] <jcastro> vds?
[15:17] <aquarius> jcastro, I'm pinging vds to take his part in the standup meeting :P
[15:18] <jcastro> oh, I suppose I'll stop interrupting, sorry!
[15:19] <vds> sorry was in a call
[15:20] <vds> DONE: working on branch to configure funambol to send sms messages #418048
[15:20] <vds> TODO: finish this branch to setup funambol to send sms messages
[15:20] <vds> BLOCKED: I'm waiting for the funambol support guys to answer to the ticket I've filed
[16:35] <urbanape> an editor wish: bzr integration that shows real time diffs on the documents I'm working on.
[16:36] <urbanape> I'm sure there's an emacs mode somewhere that does it.
[16:47] <adiroiban> hi. If this is the right channel for couchdb desktop, I have one question. In Ubuntu Karmic, any couchdb database will be synced with Ubuntu One, or only notes and contacts?
[16:47] <tcole> Well, sort of. You can create other desktop-couch databases which will be synced
[16:48] <tcole> but that doesn't automatically apply to any database you might have in a local couchdb instance
[16:49] <adiroiban> tcole: by default, couchdb replication will not create new databases
[16:49] <tcole> ah, point
[16:50] <adiroiban> tcole: does couchdb desktop also handle / initialize synchronizations?
[16:50] <tcole> I don't actually know offhand
[16:50] <tcole> urbanape: ping
[16:51] <adiroiban> on my default Karmic system, with Ubuntu One, the couchdb also contains the test suite databases
[16:51] <adiroiban> and ~/.cache/desktop-couch/log/desktop-couch-replication.log complains about them
[16:51]  * tcole nods
[16:53] <adiroiban> is this the right place to talk about couchdb dektop?
[16:53] <tcole> yes
[16:53] <tcole> I'm hoping one of the desktopcouch devs will chime in
[16:54] <aquarius> hey
[16:54] <aquarius> adiroiban, any databases in desktopcouch, except for those that are explicitly excluded, will be synchronized
[16:55] <tcole> thanks aquarius
[16:55] <aquarius> adiroiban, we go a step beyond "stock" Couch replication, in that we create the DBs in other couches (Ubuntu One, other paired desktopcouch servers) that are replicated to
[16:55] <adiroiban> aquarius: I see, so I can use Ubuntu one as my couchdb in the cloud ?
[16:56] <urbanape> tcole: pong
[16:56] <aquarius> adiroiban, that depends on what you want to use it for. You certainly can access it directly, but access to Ubuntu One's couchdb, like desktopcouch, is secured with OAuth
[16:56] <tcole> urbanape: I've got a user with a question about deleting bookmarks with bindwood -- they delete from firefox, but the bookmark is coming back
[16:56] <aquarius> adiroiban, so you can't, for example, browse Futon in a browser. You can store data in it and retrieve data from it directly, though.
[16:56] <adiroiban> aquarius: well. I have a small desktop app for keeping track of my notes and tasks
[16:57] <adiroiban> right now I'm using sqlite
[16:57] <adiroiban> but I will be happy to move the backend to couchdb using couchdbdesktop
[16:57] <urbanape> tcole: do you know what version they're using?
[16:57] <aquarius> adiroiban, excellent! I'd love to answer all the questions I can to help you do that
[16:58] <adiroiban> the problem is that it is written in vala
[16:58] <adiroiban> i start hacking the current vapi file
[16:59] <adiroiban> and it should solve the problem
[16:59] <adiroiban> but I was not sure about the scope of couchdb desktop
[16:59] <aquarius> adiroiban, ooh, vala. I don't think there is, yet, a desktopcouch library for Vala. This is a good chance to create one, though :) You could either bind couchdb-glib to Vala, or build one from scratch (based on an existing couchdb library? is there one for vala?)
[17:00] <adiroiban> aquarius: I assume I can look at evolution-couchdb implementation and implement the same logic in my app
[17:00] <aquarius> adiroiban, certainly, yes, or desktopcouch.records, which is Python; I don't know which would be easier for you to follow
[17:00] <aquarius> (the python would certainly be easier for me, but I'm more a Python guy than a C guy :))
[17:00] <tcole> urbanape: I don't; I will try to find out.
[17:01] <adiroiban> aquarius: I am not aware of any „native” couchdb lib for vala
[17:01] <urbanape> tcole: is there a bug #?
[17:01] <tcole> urbanape: right now it's still a question and I haven't converted it to a bug yet: https://answers.launchpad.net/bindwood/+question/95105
[17:01] <adiroiban> but I think a (nice crafted) binding for couchdb-glib should do the trick
[17:01] <aquarius> adiroiban, yeah, so you can either match the desktopcouch.records API or the couchdb-glib API (or invent your own, if you prefer, although sticking with an existing one would beideal :))
[17:02] <aquarius> adiroiban, the chap to talk to about details of couchdb-glib is rodrigo_, who's currently eating dinner or something :)
[17:02] <adiroiban> I don't like inventing that kind of things :)
[17:02] <adiroiban> aquarius: yep. I will hunt rodrigo later :)
[17:03] <aquarius> cool -- couchdb-glib is necessarily a more basic API than desktopcouch.records, just because C's more basic :)
[17:03] <urbanape> tcole: thanks. I have vague recollections of that being fixed a while ago.
[17:04] <adiroiban> aquarius: thanks for the info. I am happy to hear Ubuntu One can be used as a  generic couchdb replication server
[17:05] <aquarius> adiroiban, it can indeed, yep -- desktopcouch.replication handles the replication logic (in particular, OAuth-signing replication requests and so on)
[17:07] <adiroiban> aquarius: but from the point of view of a desktop app developer, I only need to care about reading and writing the local couchdb. No need for explicity replicationrequests. Is this correct?
[17:07] <aquarius> adiroiban, totally correct. You just write to desktopcouch; your data is replicated up to Ubuntu One and down to any other paired machines you have
[17:07] <aquarius> you don't have to do any of that replication; we take care of that for you
[17:07] <adiroiban> aquarius: great. just like in a perfect world :)
[17:08] <aquarius> adiroiban, that's the Ubuntu One Promise. ;-)
[17:09] <adiroiban> Is there a problem with Cromium and Ubuntu One webpage?
[17:10] <adiroiban> or Epiphany
[17:10] <aquarius> adiroiban, there shouldn't be; I'm using Chromium :) What sort of problem are you having?
[17:10] <adiroiban> I can not use the online note editor
[17:11] <aquarius> what do you mean by "can't use"?
[17:11] <adiroiban> well. I can not save notes
[17:11] <aquarius> ah, that's a server problem; it's being worked on
[17:12] <aquarius> I'm not sure where the fix is for that; CardinalFang may know more, when he's around
[17:12] <adiroiban> also the notes and contacts are not synced with my local couchdb
[17:13] <adiroiban> I was able to copy all my evolution contact to couchdb agenda
[17:13] <adiroiban> they were pushed to Ubuntu One
[17:13] <adiroiban> but I can no longer access the Ubuntu one agenda in evolution
[17:13] <adiroiban> and using Futon, I can see that contacts are not synced
[17:14] <adiroiban> is this also a known problem?
[17:14] <aquarius> http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation/Troubleshooting has some tips for if desktopcouch has got confused and stopped working with evolution
[17:15] <homeasvs> aquarius, ping
[17:15] <aquarius> homeasvs, pong! happy new year, pal :)
[17:15] <homeasvs> same to all of you!
[17:15] <homeasvs> so I have a branch of 0.5 on launchpad that uses python-keyring
[17:16] <aquarius> you are a hero of the revolution
[17:16] <homeasvs> obviously since python-keyring is a simpler api it cannot generate exactly the same secrets as with gnome-keyring
[17:16] <homeasvs> I don't know if you need migration code then to cover that case ?
[17:16] <aquarius> ah. I was worried that might happen, but I hadn't looked closely enough into pytohn-keyring to be sure
[17:16] <aquarius> thisfred, ping/
[17:17] <aquarius> homeasvs, what are the differences?
[17:17] <thisfred> yo
[17:17] <homeasvs> aquarius, I need to fix it on maemo so that it uses an unencrypted file store, otherwise dbus activation hangs because it asks for a password on the console
[17:17] <aquarius> thisfred, desktopcouch 0.5 with python-keyring! l00k! ^^
[17:17] <homeasvs> aquarius, it's a simple api - basically set_password(service, username, password)
[17:17] <thisfred> awesome!
[17:17] <homeasvs> aquarius, so none of the extra info you guys use, but I don't think that's a big deal
[17:18] <homeasvs> aquarius, my current problem on maemo is that desktopcouch-service now starts and launches couchdb, but then hangs because it can't find an avahi service file or something
[17:18] <aquarius> so we'd need to think about migration (or, possibly, having it deal seamlessly with both, rather than forcibly upgrading your keyring password, which would be better)
[17:19] <homeasvs> well, I'd have to say that the python-keyring api is a little too light to my taste
[17:19] <homeasvs> not to mention, blocking, so ugh imo
[17:19] <aquarius> homeasvs, erm...desktopcouch-service hangs? that's not supposed to happen
[17:19] <homeasvs> the keys have a generic name when you look at them in seahorse, not ideal
[17:19] <aquarius> yeah, the API's not ideal, but "don't bind desktopcouch tightly to gnome" is enough of a win that we can live with the pain of blocking simple APIs.
[17:20] <homeasvs> aquarius, oh, lots of things happened that aren't supposed to happen as I ported to fedora and maemo
[17:20] <aquarius> if there was something that was non-blocking and rich and also cross-platform then that'd be, y'know, great :)
[17:20] <homeasvs> apparently my six days erlang build on maemo is incomplete as it misses all of the ssl stuff
[17:20] <homeasvs> hm, that might be a good twisted project to start at some point
[17:20] <aquarius> ooh, that will probably mean that it won't sync to Ubuntu One if there's no SSL :(
[17:21] <aquarius> thisfred, so, what's the best way of us looking at getting this lovely python-keyring stuff into core desktopcouch?
[17:21] <aquarius> could just submit a merge proposal for review, but I'm a bit concerned about it being very invasive
[17:22] <thisfred> aquarius: we might need upgrade code if it is, which means we'll have to think about upgrade infrastructure, which we will need to do some day anyway
[17:23] <aquarius> homeasvs, I wonder about allowing python-keyring to optionally take extra parameters which are passed on to the underlying implementation, so you can add keynames in gnome-keyring...although that might be The Wrong Thing
[17:24] <homeasvs> aquarius, that's what I was thinking too
[17:24] <thisfred> aquarius: I don't know much about the preferred way to do this in ubuntu/desktop/python apps. There must be something we can use. Setuptools?
[17:25] <aquarius> what concerns me is not breaking other consumers (obvious example is couchdb-glib)
[17:25] <adiroiban> aquarius: my problem is that org.desktopcouch.CouchDB.getPort is timeout by message bus
[17:25] <aquarius> so I'd much, much, much rather not change how the keys are stored if we can possibly avoid it, rather than upgrade the key storage
[17:26] <homeasvs> https://code.launchpad.net/~thomasvs/desktopcouch/0.5-keyring <- this is the branch
[17:26] <homeasvs> first commit was 'just move keyring code to one module, creating a function for each type of key access'
[17:26] <homeasvs> ie, a refactoring of existing code
[17:26] <homeasvs> second commit was 'now use keyring instead'
[17:26] <homeasvs> and third commit was 'I did something wrong in the first commit', so sorry about that
[17:27] <homeasvs> aquarius, that's probably only possible with a) changes to python-keyring or b) some still-gnome-keyring-specific code (but doable; load keyring; figure out if it's trying to us gnome-keyring; if so, use specific code)
[17:28] <aquarius> I've got no problem with changes to python-keyring if they'll be accepted upstream, which I'd think they would be if they were generic enough?
[17:29] <aquarius> I'm thinking in terms of adding an "extras" dict to calls where you can pass specific information if you *know* which platform you're on, which will be ignored on other platforms, sort of thing
[17:31] <homeasvs> to be honest I don't really understand the attributes part of gnome keyring
[17:31] <homeasvs> what's the point of it ?
[17:32] <homeasvs> the desktopcouch secrets still end up being combinations of usernames and passwords
[17:32] <homeasvs> one of them puts 4 different pieces of info in one secret
[17:32] <homeasvs> the semantics aren't very obvious imo
[17:33] <homeasvs> and they're all 'generic secret' when it looks like for some of them NETWORK_PASSWORD would make more sense
[17:34] <aquarius> I can see that argument, certainly, and I'm not totally averse to the idea of changing how we store the secrets, I'm just worried that it makes it quite a bit harder to actually get this code out, because we need to upgrade all the consumers at once (bindwood, couchdb-glib, desktopcouch.records), and if you upgrade some but not others you break
[17:34] <homeasvs> hm
[17:35] <homeasvs> well, it looks to me first of all that gnome-keyring uses NETWORK_PASSWORD, not GENERIC_SECRET
[17:35] <homeasvs> the upgrade doesn't sound like that big of a deal, since the packages can require a new desktopcouch, no ?
[17:35] <homeasvs> I guess we should just talk to the author of python-keyring
[17:36] <homeasvs> I think in any case it makes sense to take at least the first and third commit on that branch, since it moves all keyring code to one specific module
[17:36] <aquarius> the packages can require a new DC, but you'd need a new couchdb-glib as well, for example
[17:37] <aquarius> yeah, I like the refactoring a lot
[17:37] <aquarius> because we definitely need to do that!
[17:37] <homeasvs> aquarius, why would a new couchdb-glib be a problem ? doesn't it depend on desktopcouch ?
[17:38] <aquarius> yeah, but desktopcouch doesn't depend on it, and afaik couchdb-glib isn't locked to your DC version. So upgrading DC won't upgrade couchdb-glib
[17:38]  * aquarius checks that he's not talking out if his arse
[17:43] <aquarius> yeah, evolution-couchdb just depends on desktopcouch, not on a specific version
[17:43] <aquarius> wish rodrigo was around :)
[17:45] <homeasvs> ok, well
[17:45] <homeasvs> who starts the talks with the keyring guy to see what he thinks ?
[17:49] <aquarius> I can do that (and CC the desktopcouch mailing list, and you obviously), unless you know the chap? Kang Zhang.
[17:56] <homeasvs> no, don't know him.  yeah, please do.
[18:03] <adiroiban> trying to debug desktopcouch i got this erorrs after starting /usr/lib/desktopcouch/desktopcouch-service http://paste.ubuntu.com/351894/
[18:04] <adiroiban> any hints for solving the problem. A dbus requires to getPort will not start desktopcouch on my computer
[18:06] <aquarius> adiroiban, there's no oauth token in the desktopcouch ini file. (/home/adi/.config/desktop-couch/desktop-couchdb.ini)
[18:06] <aquarius> what's in that file?
[18:06] <adiroiban> there is no such file
[18:08] <aquarius> that'd be the problem, then :)
[18:09] <adiroiban> who should create that file?
[18:16] <adiroiban> reading http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation/How_Desktopcouch_Works was not of much help for this problem
[18:17] <aquarius> adiroiban, that file's created by start_local_couchdb, iirc
[18:18] <aquarius> I don't quite understand how it's not being created for you, though
[18:19] <adiroiban> I don't know how to call start_local_couchdb
[18:20] <aquarius> you're not supposed to have to :)
[18:21] <aquarius> adiroiban, what do you get if you do: python -c "import desktopcouch"
[18:22] <adiroiban> nothing ... no errors
[18:23] <aquarius> sorry, back to basics a bit here; which system are you running this on?
[18:23] <adiroiban> karmic
[18:25] <aquarius> adiroiban, ok. Try this: python -c "import desktopcouch; print desktopcouch.find_port()"
[18:26] <adiroiban> up and running
[18:26] <adiroiban> it prints the right port
[18:26] <adiroiban> I can access the couchdb via Fulton
[18:27] <aquarius> but there's no ini file??
[18:28] <aquarius> /home/adi/.config/desktop-couch/desktop-couchdb.ini doesn't exist??
[18:28] <adiroiban> nope
[18:28] <adiroiban> no ini file
[18:29] <aquarius> ok, baffled.
[18:29] <aquarius> I don't understand how DC is starting up if it doesn't have an ini file.
[18:30] <aquarius> can you kill and restart desktopcouch as per the troubleshooting document, and then try the above find_port line again?
[18:31] <adiroiban> i tried
[18:31] <adiroiban> the problem is that I don't have beam.smp
[18:31] <aquarius> what?
[18:31] <aquarius> what does "killall beam.smp" say?
[18:32] <adiroiban> i have /usr/lib/erlang/erts-5.7.2/bin/beam
[18:32] <adiroiban> there is no beam.smp process
[18:33] <aquarius> oooooh.
[18:33] <adiroiban> this was the problem
[18:33] <aquarius> perhaps, then, I'm on a dual-core processor and it runs a different erlang
[18:33] <aquarius> interesting!
[18:33] <aquarius> so instead of killall beam.smp, try killall beam
[18:33] <aquarius> and then restart desktopcouch
[18:34] <adiroiban> well, i used kill
[18:34] <aquarius> actually, just killall beam; python -c "import desktopcouch; print desktopcouch.find_port()"
[18:34] <adiroiban> and the process number
[18:34] <adiroiban> the desktopcouch is up and running now
[18:34] <aquarius> is there an ini file now?
[18:34] <adiroiban> yes
[18:35] <adiroiban> i killed beam
[18:35] <adiroiban> and then request the port over dbus
[18:35] <aquarius> ahh, good. that's better, then :)
[18:35] <adiroiban> and I was prompted for a lot of keyrings
[18:36] <aquarius> yes. desktopcouch stores its keys in the keyring so they can be retrieved later
[18:51] <titeuf_87> using desktopcouch & python when I delete a record, that record still shows up on the different views I made
[18:51] <titeuf_87> is there a way to really delete something?
[18:52] <titeuf_87> or it's better I put a check in all my views to see if it's deleted or not? (and if so, why?)
[18:59] <aquarius> titeuf_87, at the moment, "deleted" records are actually tagged with application_annotations["Ubuntu One"].private_application_annotations.deleted = true
[18:59] <aquarius> titeuf_87, this is because CouchDB doesn't, currently, have history (where you could roll back to an earlier state), but it *will* have
[19:00] <aquarius> at which point this "deleted" hack will go away
[19:00] <aquarius> the best thing to do is to check in the views. I know this is a little annoying :(
[19:01] <titeuf_87> oh ok, that history thing sounds neat, will be nice once that works. Thanks! I'll go add that to my views now
[19:02] <aquarius> titeuf_87, some of the desktopcouch.records stuff automatically handles this for you, but not all of it quite yet. Sorry for the inconvenience, and we want history to work just as much as you do :)
[19:16] <nettrot> one.ubuntu.com just started ISEing on attempts to save a note I'm working on.
[20:00] <adiroiban> is there a way to „see” my couchdb from https://couchdb.one.ubuntu.com/ ?
[20:12] <urbanape> adiroiban: As in a Futon view? Not currently
[20:43] <adiroiban> urbanape: Futon, or other nice couchdb gui
[20:44] <adiroiban> maybe somehow oauth http request can be proxied and let futon use such a connection
[20:46] <urbanape> CardinalXiminez_: does desktopcouch.records do batchSave?
[20:49] <CardinalXiminez_> urbanape, batchSave?  No, there's no bulk method.
[20:51] <urbanape> ah. The js lib has one, and I was wondering.
[20:51] <urbanape> er, yeah, called bulkSave
[20:51] <CardinalXiminez_> urbanape, does it do anything more than for rec in rec_list: save(rec)  ?
[20:52] <urbanape> it wraps them into a POST, I believe, so that they all show up (or so I'm told) as one item in the _changes feed.
[20:54] <CardinalXiminez_> urbanape, I'll research it to see if we're missing functionality.  put_records(yes_plural)  would be useful if it's more magical.
[20:54] <urbanape> posts to _bulk_docs, whatever that does internally.
[20:55] <CardinalXiminez_> Roger.  I'll run it by tf and aq too.
[20:55] <urbanape> thanks, I was just curious. Poking around. Trying to populate a test db.
[20:56] <urbanape> easier in Python than in Javascript, funny enough.
[21:47] <urbanape> hmm, doesn't appear that bulk documents get magically wrapped up into one sequence in the _changes feed.
[21:47] <urbanape> s/magically//
[21:53] <urbanape> thisfred: ping
[21:53] <thisfred> urbanape: pong
[21:54] <urbanape> ^^ Just tested the js lib version of the bulkSave method.
[21:54] <urbanape> it still gives each document its own entry in the _changes feed.
[21:54] <urbanape> I don't think this undoes what we were discussing yesterday
[21:54] <thisfred> ah, and increments the sequence number
[21:54] <thisfred> ?
[21:55] <urbanape> yeah, each rev gets its own sequence number
[21:55] <urbanape> is what I meant.
[21:55] <thisfred> no, it only means you can't deduce the single move gesture
[21:55] <urbanape> so, a bulkSave of two docs adds two sequence numbers to _changes
[21:55] <thisfred> easily
[21:55] <urbanape> yeah
[21:56] <thisfred> so we need to take care with what all else firefox stores for the bookmarks, if anything
[21:56] <thisfred> and make sure that's in the bookmark record's app annotations
[21:56] <urbanape> yup
[21:56] <thisfred> then we should be fine, at least if FF allows us to modify it again
[21:56] <urbanape> I've got almost all the guts rewritten
[21:56] <urbanape> it's so much cleaner now.
[21:57] <thisfred> awesome
[21:57] <thisfred> cleaning guts is what we do :)
[22:03] <tcole> EOF
[22:15] <statik> oh, so much to do
[22:17] <tcole> indeed