[11:01] <miha> hello peoples :D
[11:09] <aquarius> hi miha
[11:09] <miha> hey, instace of NWO. no new age for you.
[11:09] <miha> hehe
[11:10] <aquarius> :)
[11:10] <miha> (last time "in this New World Order" was mentioned on CNN.. i guess it's official now)
[13:32] <homeasvs_> rodrigo_, ping
[13:32] <rodrigo_> homeasvs_: pong
[13:32] <homeasvs_> rodrigo_, so, I have packages for n900
[13:32] <homeasvs_> rodrigo_, but
[13:32] <homeasvs_> I have a cryptic erlang error on couchdb startup
[13:32] <homeasvs_> http://pastebin.com/d287f37b9
[13:32] <rodrigo_> hmm, what error is it?
[13:32] <homeasvs_> any idea what that's about ?
[13:33] <rodrigo_> no, we'd better ask on the #couchdb channel
[13:33] <rodrigo_> can you do it please? I'm out for a lunch, bbiab
[13:33] <homeasvs_> sure
[13:33] <homeasvs_> hm, some googling suggests I did not compile erlang with ssl
[13:33] <rodrigo_> oh, yopu already did :)
[13:33] <homeasvs_> that would, uhm, 'suck' to figure out now
[13:34] <rodrigo_> yeah
[13:34] <rodrigo_> ok, bbiab
[13:37] <aquarius> homeasvs_, "init terminating in do_boot" is a generic "it didn't start up properly for some reason" error :(
[13:37] <aquarius> homeasvs_, quite often it means "I tried to use a library and it wasn't there", which lends weight to your SSL theory
[13:37] <aquarius> homeasvs_, although I've had it do the same thing when spidermonkey wasn't available too
[13:38] <homeasvs_> aquarius, it looks like ssl, not sure though why it was not built, investigating now
[13:39] <homeasvs_> aquarius,                    --enable-dynamic-ssl-lib \
[13:39] <homeasvs_>                     --without-ssl-zlib
[13:39] <homeasvs_> that's in the deb build
[13:39] <homeasvs_> aquarius, any idea what exactly that then does ?
[13:40] <aquarius> homeasvs_, I haven't, sorry. I don't know about the build stuff; you want cardinalfang for that, I think
[13:40] <aquarius> #couchdb may be more helpful
[13:40] <aquarius> heh, in fact they are already being more helpful :)
[13:58] <homeasvs_> aquarius, rodrigo_ ok, one crash further
[13:58] <homeasvs_> it's so close I can smell it
[13:58] <homeasvs_> aquarius, will you be getting an n900 if this works ? :)
[13:58] <aquarius> progress by crashing! :)
[13:58] <aquarius> homeasvs_, I don't like physical keyboards, otherwise I'd already be agitating for one, I think :)
[13:59] <homeasvs_> aquarius, you don't have to use the physical one :)
[13:59] <aquarius> homeasvs_, yeah, but then I've got a phone which is half an inch thicker than it needs to be....
[13:59] <homeasvs_> aquarius, if half of that is couchdb, why does it matter ? :)
[14:00] <homeasvs_> but I feel you, this phone is big in comparison to my e51 from before
[14:00]  * aquarius grins. I do rather like the idea of couch on the phone, I admit it
[14:20] <urbanape> morning, all
[14:33] <rtgz> mornin.gz
[14:39] <rodrigo_> homeasvs_: cool :)
[14:42] <homeasvs_> sweet baby jesus
[14:42] <homeasvs_> I just browsed to futon running from my phone
[14:42] <homeasvs_> this calls for some food
[14:44] <rodrigo_> woohoo!
[14:58] <dobey> hmm
[15:01] <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:04] <rodrigo_> me
[15:05] <CardinalFang> me
[15:05] <aquarius> me
[15:05] <dobey> rodrigo_: should i comment on your blog or your facebook? I don't know any more what the cool thing to do is :)
[15:05] <dobey> me
[15:05] <rodrigo_> dobey: up to you, I'll get notifications on both :)
[15:06] <rodrigo_> dobey: the cool thing though is to do it via your Palm Pre :D
[15:07] <rodrigo_> dobey: and it would be super cool if you could re-review my libubutuone branch you commented on last Friday :)
[15:07] <dobey> yes i will
[15:07] <dobey> where is everyone else?
[15:07] <aquarius> jblount is off ill
[15:07] <dobey> ChipAway, urbanape: ping
[15:09] <dobey> vds: ping
[15:09] <dobey> jblount is sick and teknico is on holiday
[15:10] <dobey> rodrigo_: eh, let's get this over with :)
[15:10] <rodrigo_> ok
[15:10] <rodrigo_> • DONE: Started adding search to contacts picker. Conboy unstable testing. XML<->HTML fixes
[15:10] <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?
[15:10] <rodrigo_> • BLOCKED: no
[15:10] <rodrigo_> CardinalFang: go!
[15:10] <urbanape> me
[15:11] <CardinalFang> DONE: Attachments.  Finally figure it out.  Played with GTG started writing desktopcouch backend storage.
[15:11] <CardinalFang> TODO: Still testing weird edge cases.  May have to harass python-couchdb upstream.
[15:11] <CardinalFang> BLOCKED: None
[15:11] <CardinalFang> aquarius.
[15:11] <aquarius> ⚀ DONE:  talk to thisfred and vds about sequence numbers etc; talk to #couchdb about sequence numbers; review duty; decide on lxml, not BeautifulSoup, for html parsing with rodrigo
[15:11] <aquarius> ⚁ TODO: make tomboy first-sync experience nicer; continue work on desktopcouch developer docs; write up things learned at UDS/sprint; work with rodrigo on Music Store, much more music store architecture planning; step-by-step guide to what happens during contact sync
[15:11] <aquarius> ⚂ BLOCKED:
[15:11] <aquarius> dobey: go
[15:11] <dobey> ☺ DONE: Reviews, SSO call, Triage
[15:11] <dobey> ☹ TODO: Homework, Review/Fix #479375, Finish Backporting, Triage, Prepare releases/SRUs
[15:11] <dobey> ☹ BLCK: None.
[15:11] <dobey> urbanape: rock on
[15:11] <urbanape> DONE: Got ubuntuone-servers branch back from the dead, handed off to jblount for some CSS lovin
[15:11] <urbanape> TODO: Get it landed. Move on to other bugs and Bindwood.
[15:11] <urbanape> EOM?
[15:11] <urbanape> BLOCK: None
[15:17] <rodrigo_> sandy|lurk, aquarius: around here?
[15:17] <aquarius> ya
[15:17] <sandy|lurk> yup
[15:18] <rodrigo_> ok, so about storing HTML vs XML on our database, sandy|lurk, could you please share your concerns with aquarius?
[15:18] <sandy|lurk> sure
[15:18] <sandy|lurk> so currently there's this bug in the XML<->HTML parser
[15:18] <sandy|lurk> which messes up bulleted lists a bit
[15:18] <aquarius> yes
[15:18] <sandy|lurk> at first I thought, okay, no big deal, should only affect users who edit notes in U1
[15:19] <sandy|lurk> but then I realized that actually, you store HTML, and the conversion happens on each sync
[15:19] <sandy|lurk> well, this means anyone syncing experiences the bug
[15:19] <sandy|lurk> so even though I'm sure this will be fixed soon
[15:19] <sandy|lurk> this sort of thing could easily come up again
[15:19] <aquarius> yes.
[15:19] <aquarius> Your proposed alternative is, I imagine, store tomboy's XML in the DB, yes?
[15:19] <sandy|lurk> so I'd advocate storing the native XML format of the REST API instead
[15:19] <sandy|lurk> yup
[15:20] <aquarius> my problem with doing that is that we have to have a working html-to-xml converter for the web UI anyway.
[15:20] <rodrigo_> aquarius: well, it makes sense, since it's the format used by tomboy, conboy, tomdroid, etc
[15:20] <sandy|lurk> as I explained to rodrigo, I woudl guess that most users using Tomboy+U1 are using it for syncing, then a subset uses it for viewing too, and then a smaller subset uses it for editing
[15:20] <rodrigo_> aquarius: or an editor that knows about the XML format, would that be too hard?
[15:20] <homeasvs_> rodrigo_, check my facebook :)
[15:20] <sandy|lurk> aquarius: yeah, I sympathize with that issue
[15:20] <aquarius> rodrigo_, yep, it's too hard. I tried that. Without writing a widget completely, completely from scratch, whcih is horrific pain
[15:21] <sandy|lurk> yes, the rich editors all use HTML
[15:21] <sandy|lurk> that makes sense
[15:21] <sandy|lurk> aquarius: you could have a cache, of course
[15:21] <aquarius> sandy|lurk, I'm trying to avoid the web UI falling behind if there's a problem. This way, if there's a problem we see it immediately and can fix it immediately
[15:21] <sandy|lurk> generate the HTML only when the user actually views the note...slowish the first time
[15:21] <aquarius> cache?
[15:21] <sandy|lurk> yeah, store both
[15:21] <aquarius> yeah, but we have to back-translate
[15:21] <aquarius> from arbitrary random HTML to tomboy XML
[15:22] <sandy|lurk> aquarius: only if they edit
[15:22] <sandy|lurk> aquarius: I understand that this way you see bugs faster
[15:22] <sandy|lurk> but users see bugs immediately that they woudl not expect
[15:22] <aquarius> yeah. I'm not completely averse to the idea of storing tomboy XML in the DB, I admit
[15:22] <sandy|lurk> I would not expect simply syncing my notes to modify them in any way
[15:22] <sandy|lurk> (as a user)
[15:23] <rodrigo_> storing both formats might be ok, I guess
[15:23] <aquarius> oh, I agree
[15:23] <sandy|lurk> yeah, I don't know what your space constraints are
[15:23] <rodrigo_> homeasvs_: in a minute...
[15:23] <sandy|lurk> text is small but doubling the storage could hurt, I dunno
[15:24] <aquarius> space isn't a problem; my issue is that storing the same data twice is a flat-out invitation for them to get out of sync :)
[15:24] <sandy|lurk> but ideally, storing both would be my favorite soution
[15:24] <aquarius> if they're translatable, then you don't need to store them twice. If they're not translatable, then the web UI is irretrievably broken anyway
[15:24] <rodrigo_> yeah, and whenever you sync a note from tomboy, we need to convert, and the same when editing on the web
[15:24] <rodrigo_> which gives us the same problem, if there are new tags in the tomboy xml not understood by the converter
[15:25] <sandy|lurk> well you already convert every note during a sync
[15:25] <aquarius> my original intention was, as above, to make it so if it broke then it'd break for everyone and we'd notice and fix it fast
[15:25] <rodrigo_> yeah
[15:25] <sandy|lurk> even though most users will nver usethe HTML
[15:25] <rodrigo_> but if the converter is buggy, we have the same problem
[15:25] <sandy|lurk> aquarius: yeah, I understand that
[15:25] <sandy|lurk> but that seems pretty risky to me
[15:25] <aquarius> but I am starting to think that the better approach is to have it so when it breaks, it doesn't necessarily break everything
[15:25] <aquarius> so at least a subset of users won't experience the problem.
[15:26] <sandy|lurk> I think users using different editors on the same file may expect some weirdness
[15:26] <sandy|lurk> if I use Word and OO.o I expect formatting issues
[15:26] <sandy|lurk> ditto Tomboy and U1's note editor
[15:26] <rodrigo_> sandy|lurk: you mentioned some time ago that plugins would use their own XML markup if needed, right?
[15:26] <sandy|lurk> rodrigo_: yeah, many plugins add new XML tags
[15:27] <sandy|lurk> if your converter doesn't know about them today, I don't know what you guys do
[15:27] <rodrigo_> homeasvs_: yay!
[15:27] <sandy|lurk> if I write a custom add-in
[15:27] <sandy|lurk> that only I know about
[15:27] <sandy|lurk> and I don't share it
[15:27] <sandy|lurk> and it adds a new XML tag
[15:27] <sandy|lurk> and then I sync to U1 and it gets lost even though I don't use the editor
[15:27] <sandy|lurk> I'd be sad
[15:27] <aquarius> it should, in theory, handle it (<sandy> gets converted to <span class="sandy"> and then gets converted back)
[15:27] <sandy|lurk> aquarius: ah, cool :-_)
[15:27] <homeasvs_> rodrigo_, I'll see about getting my packages done properly, cleaning up, and putting them somewhere
[15:27] <aquarius> I did try to not have it throw away information ;)
[15:27] <homeasvs_> rodrigo_, then next step would be desktopcouch stuff
[15:28] <sandy|lurk> aquarius: thanks
[15:28] <sandy|lurk> so then the only real concern is converter bugs
[15:28] <aquarius> the current parser doesn't eat indented notes because it throws away information, it eats indented notes because it's appending children to the wrong place in the tree
[15:29] <sandy|lurk> if the bug was limited to the editor it would just be annoying
[15:29] <sandy|lurk> since it's not, it's critical
[15:29] <rodrigo_> sandy|lurk: yay, I marked it as such
[15:29] <sandy|lurk> so a bug in the converter becomes a much bigger deal all of the sudden
[15:29] <aquarius> yeah, so it comes down to a straight-up choice between 1. converter bugs get noticed quickly because they break everyone, and 2. converter bugs only affect a subset of users but are less likely to get fixed when they do happen
[15:30] <sandy|lurk> well maybe I can help with 2) by providing good complex test notes
[15:30] <aquarius> I was leaning towards 1 (that's why we store HTML), but I am now leaning towards 2, with the caveat that we have to convert everyone's existing notes :)
[15:30] <sandy|lurk> I assume you guys have unit tests
[15:30] <rodrigo_> homeasvs_: desktopcouch should be easier, I think, since python modules should be easy, right?
[15:30] <sandy|lurk> so better note data to test could help with 2
[15:30] <aquarius> good complex test notes would be good -- we do have unit tests for the converter, but they're not totally comprehensive (that's how we missed the nested-lists bug :))
[15:30] <sandy|lurk> cool, I'll try to get to that before next week then
[15:31] <rodrigo_> sandy|lurk: we have unit tests, but they don't test everything, so we're adding them
[15:31] <aquarius> do you have a set of complex notes for tomboy's own unit tests?
[15:31] <sandy|lurk> so Tomboy sucks wrt unit testing
[15:31] <sandy|lurk> but I do have complex notes in my own collection for ad-hoc testing
[15:31]  * aquarius grins
[15:32] <aquarius> us having them would help quite a lot :)
[15:32] <homeasvs_> rodrigo_, yeah
[15:32] <sandy|lurk> when we were rewriting printing we came up with some fun gnarly notes to test with
[15:32] <homeasvs_> rodrigo_, I guess it will depend on whether we need ubuntuone-storage-protocol
[15:32] <aquarius> we need to have a working converter first, though, so we can convert the stored format for current notes
[15:32] <sandy|lurk> okay, I've got to run...employee meeting starting
[15:32] <aquarius> sandy|lurk, cheers!
[15:32] <rodrigo_> homeasvs_: that's for file sharing, so I guess not
[15:32] <homeasvs_> but even then, should still be doable.  Just want to clean up the current mess first before moving on, since I will probably need to pull in some couchdb patches as well for oauth
[15:32] <sandy|lurk> I also want to talk to you guys about note attachments at some point
[15:33] <homeasvs_> rodrigo_, right, but I want to easily pair with u1 on the phone
[15:33] <aquarius> homeasvs_, you don't need any ubuntu one stuff at all for desktopcouch.
[15:33] <rodrigo_> homeasvs_: ah, ok
[15:33] <rodrigo_> go homeasvs_ go! :D
[15:33] <aquarius> homeasvs_, you need a little bit of it in order to replicate couch to u1, but not much (just enough to get the oauth tokens)
[15:33] <rodrigo_> sandy|lurk: are attachments supported already in tomboy?
[15:33] <sandy|lurk> ie, how should we modify the REST API to support notes having files attached to them (images for example)
[15:33] <rodrigo_> sandy|lurk: ah ok
[15:33] <aquarius> sandy|lurk, that sounds like it'll be a fun conversation :)
[15:34] <sandy|lurk> rodrigo_: no, but I was working on it the other day
[15:34] <aquarius> sandy|lurk, ah! ok, good, I thought it was going to be a kicking for us about not supporting them ;)
[15:34] <rodrigo_> sandy|lurk: for images, I guess we need them
[15:34] <aquarius> sandy|lurk, happy to think about that, definitely :)
[15:34] <sandy|lurk> cool, thanks for the chat guys
[15:34] <rodrigo_> from our POV it should be easy, since we can store attachments with the couchdb documents
[15:34] <aquarius> yeah, as long as no-one attaches an iso image to a note or something ;)
[15:34] <rodrigo_> sandy|lurk: thanks to you :D
[15:35] <rodrigo_> aquarius: :)
[15:35] <rodrigo_> homeasvs_: oh, you mentioned the sdk repo in some facebook message, where is that?
[15:35] <rodrigo_> homeasvs_: I haven't seen anything about it when looking for repos
[15:36] <homeasvs_> rodrigo_, it's the one that is in your scratchbox
[15:36] <homeasvs_> deb http://repository.maemo.org/ fremantle/sdk free non-free
[15:36] <rodrigo_> homeasvs_: ah
[15:37] <aquarius> rodrigo_, so I think that we should 1. get the converter working 2. change the back-end storage format to tomboy XML 3. convert all the currently-stored notes
[15:37] <rodrigo_> aquarius: step by step, I'll work on 1 first :)
[15:39] <mandel> CardinalFang: ping
[15:39] <CardinalFang> mandel, hi
[15:40] <mandel> CardinalFang: hello, did u see my message regarding the record_id branch?
[15:41] <mandel> CardinalFang, all that conversation about the if statement and at the end I used to wrong logic <embarrassed>
[15:41] <CardinalFang> mandel, I haven't seen that message yet, no.
[15:41] <mandel> https://code.edge.launchpad.net/~mandel/desktopcouch/record_id/+merge/15424
[15:41] <mandel> CardinalFang, last message
[15:42] <mandel> CardinalFang, guillermo just changed to approved, but the code will not work
[15:42] <verterok> mandel, CardinalFang sorry :/
[15:42] <verterok> it has 2 approves...
[15:43] <verterok> mandel: CardinalFang: should I cange it back to Needs review/reject?
[15:43] <sandy|lurk> rodrigo_: here's a test note that was great for printing, though it only goes two-levels deep for bulleted lists: http://bugzilla-attachments.gnome.org/attachment.cgi?id=127654
[15:43] <mandel> verterok, CardinalFang, I would, you can blame me, it was my fault :P
[15:43] <verterok> mandel: should I change it to needs review?
[15:44] <mandel> verterok, I would
[15:44] <verterok> ok, done
[15:44] <verterok> mandel: thanks for pinting this out :)
[15:44] <mandel> verterok, no problem, the new version in the branch has the correct logic plus a test to avoid any other problems like this
[15:45] <mandel> verterok, totalmente mi culpa ;)
[15:45] <verterok> mandel: ooh, I see. you should "resubmit" the branch ;-)
[15:45] <mandel> verterok, will do
[15:46] <mandel> verterok, I just have to do a second merge proposal?
[15:47] <verterok> mandel: no, from the merge proposal pag you can resubmit it, and launchpad creates a new merge proposal that superseeds the current
[15:47] <CardinalFang> verterok, mandel, usually it is best to push a new branch, but there's no reason to bother now.  Everyone who cares is here listening and knows what's going on.
[15:47] <CardinalFang> mandel, there's no red tape here.  Let's worry about the bug instead.
[15:48] <mandel> CardinalFang, so I just do a superseed merge, ok
[15:48] <CardinalFang> verterok, (I don't think one can resubmit a merged branch.  I may be wrong.)
[15:49] <verterok> CardinalFang: it's merged?
[15:49] <CardinalFang> Yes.
[15:49] <verterok> ooh, that's a different story
[15:49] <verterok> mandel: ^
[15:49] <CardinalFang> mandel, just push it as you intended to.  It's all good.
[15:50] <mandel> CardinalFang, verterok, so I do not do anything, right?
[15:50] <mandel> CardinalFang, verterok, I feel kind of stupid for that error...
[15:51] <verterok> mandel: what CardinalFang said
[15:51] <mandel> ok
[15:51] <verterok> mandel: no worries, I reviewed the branch and didn't see it :/
[15:55] <mandel> CardinalFang, I have pushed a new version of the branch with the changes + test
[15:55] <mandel> CardinalFang, although I can always push to a diff branch to make it explicit
[16:06] <CardinalFang> mandel, there's a problem with your test.  I'm adding a comment.
[16:15] <CardinalFang> mandel, comment added.  Needs fixing.
[16:15] <CardinalFang> https://code.edge.launchpad.net/~mandel/desktopcouch/record_id/+merge/15753
[16:17] <mandel> CardinalFang, cool I sort it out right away, I di dnot know that :D
[16:31] <mandel> CardinalFang, changed made, sorry for the pain in the ass
[17:47] <urbanape> aquarius: you aboot?
[17:47] <aquarius> otp
[17:47] <urbanape> k
[17:48] <urbanape> also for CardinalFang and thisfred: was thinking more about the way we'll handle delete in the future. If clients push content that has been seen before, presumably we'll need to provide a recognizable response so the client knows it can deal with the record properly.
[17:49] <urbanape> "Hi, here's this bookmark."
[17:49] <urbanape> "Bah, our user deleted that weeks ago. Begone!"
[17:49] <urbanape> what HTTP response code would you use? Bad Request?
[17:50] <urbanape> 406 Not Acceptable?
[17:50] <urbanape> 410 Gone
[17:51] <urbanape> I think 410 matches that story.
[17:51] <rmcbride> 411 "highly embarrassing"?
[17:51]  * rmcbride makes up HTTP response codes at randome
[17:51] <CardinalFang> urbanape, I think upstream couchdb will be a better place to handle that, and I bet they will have something already planned.  Maybe jan____ knows.
[17:52] <urbanape> do you know off-hand what the conditions will be for determining identity? presumably the couch _id, right?
[17:53] <urbanape> software is hard. let's go shopping.
[17:56] <CardinalFang> jan____, without consulting #couchdb at all, we've been tossing around ideas for understanding and dealing with documents that are expunged from a database, so that replication doesn't reintroduce them.
[17:57] <urbanape> jan____: particularly when Couch isn't the primary storage, but is the replication medium.
[17:58] <thisfred> again: replication does not reintroduce deleted documents...
[17:58] <CardinalFang> Ah.
[17:58] <urbanape> thisfred: it's not about the replication
[17:59] <thisfred> right
[17:59] <CardinalFang> So it is a positive event.  Sorry.
[17:59] <urbanape> in Bindwood
[17:59] <urbanape> so that other clients don't reintroduce them
[17:59] <urbanape> (not replication, correct)
[18:00] <thisfred> I think the way to solve this is to monitor _changes, and act accordingly
[18:00] <urbanape> yes, but the question is what to monitor in changes? There has to be a there there to monitor
[18:00] <urbanape> if deletions show up as a document in the _changes feed, we're fine
[18:00] <thisfred> urbanape: ah, do delete events not show up?
[18:00] <thisfred> that would be an unfortunate omission
[18:00] <urbanape> I don't know, we don't delete documents
[18:01] <urbanape> lessee
[18:01] <thisfred> right, so we don't have the problem yet, or do we?
[18:02] <urbanape> yes, they show up in changes
[18:02] <urbanape> with a deleted flag
[18:02] <urbanape> yay, we're done.
[18:02] <urbanape> champagne and caviar, for everyone!
[18:02] <thisfred> Can I have double champagne if I pass on the caviar? :)
[18:03] <urbanape> no. Eat your fish eggs and like 'em.
[18:03]  * thisfred mopes
[18:03] <urbanape> CardinalFang: we (at least Bindwood) have no problems in this regard any longer.
[18:03] <urbanape> forget I ever ranted and/or raved.
[18:04] <urbanape> we'll actually just do delete documents and pull those changes from _changes when we normally poll.
[18:05] <aquarius> urbanape, yo
[18:05] <urbanape> aquarius: never mind, we solved it.
[18:06] <aquarius> urbanape, oh, good. I shall read the scrollback :P
[18:08] <urbanape> summary: deleted docs show up in _changes with a deleted: True field in the record.
[18:09] <urbanape> so we don't need to tag records with deleted, now that we're polling _changes. We can just tell Couch to delete the doc, and it'll show up for other clients in _changes.
[18:09] <urbanape> We don't need to wait for history.
[18:13] <aquarius> as long as bindwood polls _changes, yeah. Excellent. That's just excellent, is what that is
[18:14] <aquarius> now all we need is chromium support for shelling out and then I can have my bookmarks back again :P
[18:25] <urbanape> yes, I need to hang out in #chromium some more.
[18:26] <urbanape> I just think it might be beyond their scope.
[18:26] <urbanape> Expeciallly in light of Chrome OS.
[18:27] <urbanape> "What would you shell out to? There is only the browser. What would you gain from an environment (in an env sense) that is only the browser?"
[18:28] <urbanape> and I don't think they want to entertain the notion of extensions that only run on "desktop OSes"
[18:30] <dobey> NOT A DESKTOP
[18:31] <dobey> kthx
[18:32] <dobey> :)
[18:32] <urbanape> your pedantry is quaint, but I don't think you're going to convince the world.
[18:34] <urbanape> I'm gonna start just calling everything jeejahs.
[18:34] <dobey> desktop jihad
[18:34] <dobey> convert or die :)
[18:35] <dobey> can we not get bookmarks and passwords out of chrome?
[18:36] <dobey> if not, it sounds like an antitrust suit waiting to happen :)
[18:37] <urbanape> we can get bookmarks. Not sure about passwords.
[18:37] <urbanape> the problem is we can't shell out to get our dbus couch port or get at our oauth tokens.
[18:38] <dobey> oh we can't run python?
[18:38] <urbanape> we can't shell out period.
[18:38] <urbanape> we can't run an external process
[18:39] <dobey> yes, that's what i was saying
[18:39] <dobey> do they provide some way to access local disk data from internals?
[18:39] <dobey> (please don't say "HTML5 storage")
[18:40] <urbanape> I believe you can get to file:/// resources, but I don't think there's a way to get to $USER from javascript, so per-user files would be hard to do.
[18:40] <urbanape> still learning some of this stuff, so it might be possible.
[18:41] <dobey> and you probably can't do things like read/write from/to unix sockets
[18:41] <urbanape> hmm, you can use NPAPI for "legacy" stuff.
[18:41] <dobey> what the heck is "legacy"?
[18:41] <dobey> certainly not a 2TB hard disk
[18:42] <urbanape> http://code.google.com/chrome/extensions/npapi.html
[18:42] <aquarius> "legacy": "anything that we don't explicitly provide as an extension API"
[18:45] <dobey> "anything that isn't google docs"
[19:00] <CardinalFang> aquarius, thisfred, mandel,  https://code.edge.launchpad.net/~cmiller/desktopcouch/attachments/+merge/15765
[19:00] <CardinalFang> Review?  Complain?
[19:00]  * CardinalFang acquires comestibles.
[19:04] <aquarius> CardinalFang, why block overwriting of an existing attachment? to stop people doing it by accident?
[19:14] <CardinalFang> aquarius, Yes.  I want anything that destructive to be explicit.
[19:14] <aquarius> but record["foo"] = "bar" is destructive too, no? even if record["foo"] == "quux"
[19:14] <aquarius> and changes aren't *saved*
[19:15] <rtgz_> Just a thing I wanted to ask some days ago. Where does the diff containing debian/ directory come from for ubuntuone-client lp trunk?
[19:17] <CardinalFang> aquarius, They may understand index or key assignments, but the verb "attach" doesn't convey "be sure not to have the same name already, or you lose".
[19:17] <CardinalFang> replace() ?
[19:17] <aquarius> I see your point.
[19:18] <aquarius> don;t want replace() since most of the time you're not replacing anything
[19:18] <aquarius> yeah, maybe you're right. :)
[19:39] <mandel> CardinalFang, looking at it right now
[19:44] <mandel> CardinalFang: what about using an update rather than detach, attach???
[19:46] <thisfred> CardinalFang: looks good to me. Just one questions: Why do we not want CouchDB to provide ids for documents?
[19:46] <CardinalFang> thisfred, they say it's a bad idea.
[19:47] <thisfred> really?
[19:48] <mandel> thisfred, yes, it should be done in the client side, I had to do the same in my code
[19:48] <thisfred> Is the algorithm broken, or are there collission issues?
[19:48] <CardinalFang> From python-couchdb cleint.py  :  """Note that it is generally better to avoid the `create()` method and instead generate document IDs on the client side. This is due to the fact that the underlying HTTP ``POST`` method is not idempotent, and an automatic retry due to a problem somewhere on the networking stack may cause multiple documents being created in the database."""
[19:49] <thisfred> anyway, that's just curiosity. If it's a better idea not to, I'll change the server side code not to do it either
[19:49] <thisfred> CardinalFang: ah yes, that makes sense
[19:50] <thisfred> Not having transactions is the price we pay
[19:50] <CardinalFang> thisfred, I changed the server class, "put record".
[19:51] <mandel> thisfred, adding to what CardinalFang said: http://www.atypical.net/archive/2009/05/12/couchdb-090-bulk-document-post-performance
[19:51] <thisfred> CardinalFang: right, should be enough, just checking that I'm not putting anything else bypassing the API
[19:51] <thisfred> like users
[19:51] <urbanape> hmm, I was just about to noodle on how bindwood could drop the FF-generated UUIDs in favor of getting the next id from Couch and use that as the unifying foreign key.
[19:52] <urbanape> or am I misunderstanding that? Are they suggesting that clients generate ids for documents?
[19:53] <mandel> urbanape, yes, from my understanding, the client should generate the id
[19:54] <urbanape> even on id-less PUTs?
[19:55] <mandel> CardinalFang, got a question, why do you have a try block in list_attachments??
[19:55] <CardinalFang> urbanape, Yes.  HTTP isn't smart enough.  If you're going to be stateless, you have to be able to handle when you're redirected several times.  A (e.g.) proxy between you could PUT more than once, and that would cause problems.
[19:56] <urbanape> CardinalFang: fair enough, I suppose
[19:57] <CardinalFang> mandel, good find.  No reason, now.  I was creating _attachments somewhere else.  Now I make it at __init__(), and so I can be sure it exists.  I'll remove it.
[20:00] <mandel> CardinalFang: in the detach, you will have a keyword error when poping, do you want to give the default message or put your own? Maybe  "not existent attachment or empty" or something of the kind
[20:01] <mandel> CardinalFang, of course when working with an empty dict or none existing keyword, but I'm sure you knew what I meant ;)
[20:11] <CardinalFang> mandel, Okay, I added more descriptive KeyErrors.  Thank you.
[20:17] <mandel> CardinalFang, One last thing, if you are going to generate the id in the client side, why not moving that to the record constructor when the record_id or data["_id"] is none.
[20:18] <mandel> CardinalFang, I know it is less lazy, but from my point of view it looks nicer
[20:18] <mandel> CardinalFang, one stored the other one takes care of the id, but this is just my opinion
[20:19] <CardinalFang> mandel, I want to keep as much as possible like the old behavior.
[20:20] <mandel> CardinalFang, ok, I understand. Then everything looks great!
[20:21] <mandel> CardinalFang, I'l use it as soon as it is merged, thanks!
[21:03] <BlackPho> Hello
[21:04] <CardinalFang> Phở?  Yum.
[21:35] <kjoller> I have just gotten a (well, two) share-e-mails, but when I press the link, I get a "Something has gone wrong (500)". Nothing is available through the Ubuntu One folder either.
[21:39] <verterok> kjoller: hi, yes it's a known issue, it will be fixed real soon
[21:39] <kjoller> verterok: ok, great, thanks
[21:54] <statik> verterok, pfibiger: do we need a rollout before sharing is fixed?
[21:55] <statik> i am so woefully behind on things
[21:56] <dobey> statik: "A plan is just a list of things that don't get done."
[21:56] <verterok> statik: yes, the fix already landed
[21:57] <statik> cool, thanks
[22:16] <chatZilla> how do i relocate my files on ubuntuone to a different folder or rename a folder?
[22:31] <homeasvs_> sweet, python-couchdb is now also working on maemo
[22:31] <homeasvs_> and my commandline app runs too
[22:31] <homeasvs_> next up, a gui
[22:33] <jan____> CardinalFang: urbanape: ping me tomorrow CST time for discussion, sorry!