[00:02] I copied 750 files of about 11M total into my Ubuntu One directory, and syncd appears to be caught in some kind of loop, using 100% cpu and calling calculate_hash over the same two directories over and over again. Any ideas? [00:12] <__lucio__> hackel, put ubuntuone in debug, restart and contact facundobatista (tomorrow) [01:42] hackel, don't, we already have a bug about that [01:42] hackel, it's a known issue... stop the client and restart it [01:43] hackel, and avoid renaming a directory from .u1conflict to a non-conflict name [01:43] hackel, if you're interested, I can point you to the relevant bugs, for you to mark them as "it happens to me too" [01:43] __lucio__, ^ === teknico is now known as teknico_away === teknico_away is now known as teknico [13:38] https://wiki.ubuntu.com/UbuntuOne: This protocol is built on top of Google Protocol Buffers (a sort of fast binary XMLish schema language). This abstraction is to allow extension of the u1storage protocol with breaking compatibility. [13:38] wow [14:21] Hello [14:21] I'm having a bit of an issue logging into Ubuntu One via the website on Windows [14:21] Headed to http://one.ubuntu.com and then clicked on Sign in. [14:22] I log in successfully and I am taken back to the Ubuntu One homepage and it is still showing the same original page (Sign in) - how do I access my files? [14:27] JGJones: hi, what browser are you using? [14:27] JGJones, could you please provide the version of you rbrowser? [14:27] verterok, ops, me is too slow today :) [14:27] sorry forgot to add that - latest version of Firefox [14:27] rtgz: :) [14:27] And I'm on Windows Vista [14:27] I'm primarily after my Tomboy notes here. [14:28] JGJones, are you able to browse https://one.ubuntu.com/notes/ directly? [14:29] Ah yes I am thanks [14:29] that solve my problem - although the log in process is a tad broken? [14:29] JGJones: I just login and it worked, FF3.5 @ Ubuntu [14:30] probably the log in process got some redirect loop, i.e. openid login targeted the sign in page... [14:30] * rtgz checks on win 7 (emulated, so don't worry :) ) [14:30] JGJones: you can try removing the cookies [14:30] verterok, I'm on Windows Vista - however I did not have any problem on Ubuntu last time I did it. [14:31] Will try deleting cookies later on. [14:31] verterok, no, it is not cookies [14:31] rtgz: you can reproduce it? [14:31] verterok, otherwise it would not be possible to access notes directly. [14:33] rtgz, did you get the same issue in Windows 7? [14:33] verterok, JGJones hey, i am still starting it... And it is already asking things about my virtual network and whether I like to allow firefox update to update my system... [14:34] * JGJones goes to fire up Ubuntu - my notes aren't sync'ed...the one I wanted isn't there. Oh well. [14:35] * rtgz is all for 'Synchronize Now!'-free notes syncing, simply to local CouchDB [14:38] JGJones: clearing cache might help too [14:38] rtgz: that's coming soon, hopefully [14:39] rtgz - windows 7 can't still be starting up? [14:39] JGJones, nope, not reproducible and I don't think it is windows-specific, to be honest [14:39] Hmm ok [14:40] I'll clear out my cache and see if I can do it again [14:40] rodrigo_, yep, it is possible to set up a service that will read the .notes and put them to couchdb and fetch the updates from couchdb into notes but the applications might not be that happy about the files being changed while they are running... [14:41] OK panic's over folks [14:41] rtgz: well, the idea is to make tomboy write to couchdb directly [14:41] JGJones, were you redirected to the launchpad OpenID login page or the original ubuntuone page telling you to back up your life with the big SIGN IN button? [14:41] Just cleared out cache and things was fine once more. [14:41] rodrigo_, please please pick GNote :) [14:42] rtgz: I won't, but you can if you want :D [14:42] rtgz, When I went to Ubuntu One home page - clicked on the Big Red Sign In button - and was taken to the launchpad login page. I then logged in successfully and I was taken back to the ubuntu one home page...with the Big Red Sign In button. [14:43] After clearing out the cache - it works as expected - logging in takes me to the files page. [14:43] JGJones, okay... trying to reproduce... [14:43] so flushing out cache worked - although what caused it to not work in first place before clearing cache I have no idea. [14:44] i think perhaps firefox incorrectly caches the login page, and the redirect after successful log-in causes it to load the wrong page from cache [14:48] dobey, the return_to should go to https://one.ubuntu.com/auth/complete/?janrain_nonce and afterwards the redirect is to https://one.ubuntu.com and yes, it is possible that the subsequent /files redirect failed. Just got it in lynx [14:48] dobey, no idea whether lynx is supported or not :) [14:48] rtgz: i know what it *should* do [14:49] dobey, I believe you are in Foundations+, right ? [14:49] no [14:50] well hope mine's just one of those random rare case [14:50] * rtgz knows three new words, Desktop+, Foundations+ and Ops+ and tries to apply them whenever possible... [15:00] Desktop+ MEETING BEGINS [15:00] Hello: dopey CardinalFang Chipaca jblount rodrigo_ teknico thisfred, time for a meeting! Please respond with "me". We'll go in that order repeating statuses in the format: DONE / TODO / BLOCKED [15:00] dopey? :) [15:00] Heh [15:00] thisfred does not belong to us ;) [15:00] :) [15:00] Or his smarter and more aware cousin dobey [15:00] me [15:00] me [15:00] * jblount is going to cut his fingers off later and try out some speech to txt software [15:00] me [15:01] me [15:01] me [15:01] jblount, maybe only the second part, pretty please? [15:01] me [15:02] teknico: :) [15:03] rodrigo_: At your leisure! [15:04] • DONE: Contacts picker. More music store discussions [15:04] • 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:04] • BLOCKED: no [15:04] teknico: go! [15:04] DONE: started exposing SMS methods in Funambol Server API (#381398), discussed various Funambol issues with Funambol people, done some reviews [15:04] TODO: do more reviews, finish exposing SMS methods in Funambol Server API (#381398), triage my 20 bugs [15:04] BLOCK: none [15:04] next: jblount [15:04] DONE: Got a branch sorted to fix a bunch of bugs that kept dropping off my radar [15:04] TODO: Land that branch, get started on some polish for the /files/ ui that has been on my todo list for a while [15:04] BLOCKED: Seriously considering doing my normal run with a gorilla mask on. I can't make my mind up abut whether or not I would survive the whole run, or if I would have to take off the mask because of heat exhaustion. [15:04] aquarius: ACK! [15:04] ⚀ DONE: music store planning; music store user flows mockup [15:04] ⚁ TODO: look at oauth-enabling twisted; 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; talk to thisfred and vds about sequence numbers etc [15:04] ⚂ BLOCKED: [15:04] vds1: go [15:04] DONE:updated bugs about migration to funambol v8 working on a branch to close #381398 mail to funambol support, skype with funambol, support ticketing with funambol support...ok you got it.... [15:04] TODO: finish the branch, talk with Chipaca and mattgriffin about clients, [15:04] BLOCKED: nope [15:04] dobey: go go go [15:04] ☺ DONE: Triage, Arguing with Aquarius (it builds empires), Review of U1 Application Spec [15:04] ☹ TODO: Finish Backporting, Triage, Prepare releases/SRUs [15:04] ☹ BLCK: None. [15:05] urbanape: wake up, before you go go === vds1 is now known as vds [15:05] * aquarius laughs [15:05] jblount: you forgot him btw :) [15:05] DONE: attachments API work. [15:05] TODO: more attachments work. Get it right the first time. [15:05] BLOCKED: None [15:07] jblount: re: gorilla suit, be wary of other gorillas searching for a mate [15:07] dobey: I also called you dopey, I'm a bucket of broken today. [15:08] dobey: Good point about gorillas-in-heat. Maybe I should skip the mask until I can confirm the amount of local apes. [15:08] CardinalFang, hey, nice, attachments stuff :) [15:09] jblount: i don't know if you have any banana trees in mt. dora either, so you might starve [15:12] * dobey discovers a new genre of music via spam [15:13] dobey: actually bananas grow pretty well here [15:13] rmcbride: i know. cypress gardens had plenty. [15:13] hmm. I totally need to get some banana plants [15:14] DONE: Sick kid. Before that, keeping the dream of our new lazr-jsified ubuntuone-servers branch alive, still need to do a better job with lazr-js as a sourcedep (or full-on .deb) [15:14] soz, all [15:14] TODO: Go over my bug list. It's growing. [15:14] BLOCK: None [15:14] rmcbride: i don't know if many people have them planted in suburban areas though :) [15:14] dobey: my neighbors across the street have a plant I'm looking at now. It's about 20 feet tall [15:14] or maybe more [15:15] nice [15:15] i wonder if i could grow one here [15:17] blimey, I'm meant to hack on lazr.js, aren't I? [15:17] had better do that. urbanape, if there's anything you'd like me to pick up there, let me know [15:18] aquarius: I wouldn't mind pairing with you on it [15:18] urbanape, happy to do so, when you're free [16:23] * rtgz came with peace, from Empathy... [16:24] nope, my logger does not pick up IRC conversation, sad :( [16:30] re: bug #412716 [16:31] Launchpad bug 412716 in ubuntuone-client "web ui should ellipsized filenames when too long" [Undecided,Fix released] https://launchpad.net/bugs/412716 [16:32] ? [16:32] is that the right number? :) [16:33] aquarius: yes, is there any image-like pastebin around here? :) [16:33] okay, will put to my local web server [16:33] imageshack.us? [16:33] http://buzz.rtg.in.ua/~rtg/truncating.png [16:34] rtgz, ah, I know that that bug number is right about the problem [16:34] I just don't understand what that's got to do with your logger not picking up IRC conversation :) [16:35] (also, add that image to the bug?) [16:35] so, re: the bug above - this looks pretty strange, to have filenames shortened in such a manner. This is a full-screen window on 1280x800 in firefox with pretty much default fonts [16:35] the logger is a completely separate thing, just needed some channel other than xmpp to test. Since this is my favorite.... :) [16:36] heh, gotcha [16:36] yeah, it's obviously a bug [16:36] jblount may be your chap for that, or urbanape [16:37] aquarius: it is just reminds me about 8.3 filenames [16:37] rtgz: Yeah, the file names are too short. I've worked out what I'm going to do, just haven't landed the changes yet. [16:38] I thought jblount would already be on the case :P [16:38] I'm planning on using a format similar to what gmail does, letting the filename trail off when it hits the edge of the row there. [16:38] jblount: ah, it's just it was marked as Fix Released, so I thought that it is too late :) [16:38] At present I think we're being too clever and ending up making it yucky for most people. [16:39] jblount: 01-massi…ng).mp3 [16:39] jblount: radiohea…ice.ogg [16:40] pretty much strange filenames for the audio files :) [16:40] rtgz: You're seeing a "?" in the file name? That should be an ellipsis ("...") [16:40] it is an ellipsis [16:40] the process of finding the right file starts to be much more interesting... [16:40] jblount unicode fail :) [16:41] lame [16:41] jblount, xchat-gnome shows it as an ellipsis [16:41] the first is massive attack by teardrop (theme song) and the second is Radiohead, Karma Police :) [16:41] rtgz, is that first one Daydreaming by Massive Attack? [16:41] ha! [16:41] wrong MA song. [16:42] aquarius: almost there, teardrop by massive attack :) [16:42] aquarius: Stupid terminal window in propietary operating system that runs photoshop shows a "?" :p [16:42] jblount: it does not add readability too :) [16:42] jblount, there is a lesson, there ;-) [16:42] aquarius: Noted! [16:43] * aquarius grins [16:43] I get ellipses, you get Photoshop [16:43] so, should I attach my screenshot of the scary filenames? [16:43] sounds like a fair division, to me [16:44] and I bet I can make a full folder of files with filenames that look like duplicates on the web ui... ;-) [16:45] rtgz: there's a second bug about making the truncation longer [16:45] but that bug is definitely done [16:46] urbanape: ah, so it started showing ellipses, but filenames became too short so that new bug says they should be longer, right? [16:46] rtgz: bug #451997 [16:46] That's what i get for not checking in to see what bug we're talking about! [16:46] Bug 451997 on http://launchpad.net/bugs/451997 is private [16:46] d'oh [16:46] private [16:47] why can't I make it public? [16:47] urbanape: Re bug #443121 - the tests here on a local pc also show the firefox is running instead of hanging :) [16:47] Launchpad bug 443121 in bindwood "With Bindwood installed, Firefox is completely unresponsive" [Critical,In progress] https://launchpad.net/bugs/443121 [16:47] are you running my PPA package? [16:48] urbanape: webkit [16:48] https://bugs.edge.launchpad.net/ubuntuone-servers/+bug/451997/+index [16:48] Ubuntu bug 451997 in ubuntuone-servers "Filenames shortened unnecessarily in the web UI" [Medium,Triaged] [16:48] jblount: aha [16:48] yeah, in Chromium [16:48] urbanape: To be more clear, in webkit browsers the little edit icon doesn't show up. [16:48] that seems suboptimal [16:50] urbanape: yes, i am using the ppa version, however I don't understand how the bookmarks get organized, what are being synced, but that is completely another question. [16:51] urbanape: Yeah, it's a known issue with a bug though. [16:51] well, we had an intentional goal of having no UI. Currently, we just sync all bookmarks to the desktop couchdb. [16:52] rtgz: we don't (yet) preserve the hierarchical ordering of bookmarks between machines using the same profile, but that's coming soon. [16:52] the unresponsiveness issues sorta trumped all development in that direction. [16:52] and I'm still a little unhappy with the current state of it. It cuts down the amount of work Bindwood does, but still causes a PITA lag on the first sync. [16:53] (for anyone with lots of bookmarks) [16:59] * rtgz *whispers* favicons :) [17:00] and one more, urbanape, does deleting a bookmark in firefox trigger some action in Bindwood? [17:08] rtgz: yes, deleting in firefox marks the couchdb record as deleted, but doesn't actually delete. This is to allow secondary clients to delete local copies [17:09] (otherwise, secondary machines might re-propagate the same bookmark back up to couch, where it'd show up again on the first, leading to frustration, torches, and pitchforks) [17:09] favicons have been requested before. [17:10] we provide a view in futon for the deleted bookmarks, so if you know it's been deleted on all the appropriate client machines, you can delete the records from couch. Clumsy... [17:12] urbanape, what do you need for favicons? Storage? [17:17] nah, it's just the way Firefox adds them to bookmark records. [17:17] favicons are tiny -- we could either make them attachments (ha! CardinalFang looks interested), or just base64-encode them [17:17] They're annotations, and happen out of band [17:18] I believe they're actually stored as URLs on the annotation [17:18] not hard, just needs tracking. [17:18] and Firefox usually does its own job of fetching them as the bookmark is accessed [17:18] (if it's not already set) [17:19] so they don't need storing at all, then? [17:19] probably not [17:19] urbanape: is deleting uses the desktopcouch approach, i.e. application_annotations["Ubuntu One"].["deleted"] ? [17:20] rtgz: it's a top-level field, not under application_annotations [17:20] it marks the record itself as deleted [17:20] urbanape: hm, when I tried to delete bookmarks via dc they all got new Ubuntu One/deleted annotation :-/ [17:21] * urbanape pokes someone in charge of dc. Like aquarius. [17:21] This doesn't feel like an application annotation. It's not application specific. [17:22] it's semantic to the record itself. [17:22] No, it isn't. But we can't just slam a top-level "deleted" field into any arbitrary record [17:22] it's in a_a.UbuntuOne because that's a sort of "semantic to the record but not at the top level" location [17:22] urbanape: yep, it does not, but "db.delete_record(document["id"])" insists on application_annotation... [17:23] and a_a.U1.deleted is a workaround for couch not yet supporting history. [17:23] aquarius: we can slam a top-level delete field if we account for it in the schema [17:24] yeah, but then everyone has to account for it in the schema :) [17:24] and? [17:24] * rtgz starts the vm to give a screenshot of how the world looks like w/o favicons... [17:25] and then everyone has to rev their schema to not include it the day couch supports history [17:25] this is a wart, no two ways about it [17:27] right, but now I have to rev Bindwood, and provide for understanding both deletion markers. [17:27] urbanape, yeah, I know :( [17:28] I wish I had a better solution. i hate tagging stuff as deleted rather than actually deleting it :( [17:28] urbanape: or provide some conversion script that will "fix" the records [17:29] so, in the future, will couch propagate some sort of deletion event via _changes? [17:29] how will secondary machines know to delete a record? [17:29] I've been thinking about this. [17:29] rtgz: bleah. [17:29] aquarius: yes, btw, it takes real space on your server, e.g. my bookmarks now weight 6 Mb of not-accountable-on-the-web space, notes take 8Mb and it is grooowing... [17:29] I'd rather keep the code around as a sign of shame. Like a big read "A" [17:29] red, even [17:30] rtgz, have you compressed your DBs? [17:30] urbanape, I *think*, and I'm not sure about this, that if you see a space where you want to put a record, you should check whether there *used* to be a record there by looking in the history. I think [17:30] wha? [17:31] aquarius: okay, bookmarks now weight 6Mb and notes take 3 :) [17:31] heh [17:32] rtgz, so you actually have 6MB of bookmarks? [17:32] actually, that will require clients to try and push every bookmark on every start [17:32] which gets back to a huge pile of PITA. [17:32] urbanape, this is why I'm not sure about exactly how it should work [17:32] aquarius: actually this is why i wanted to delete all duplicating records and instead received 1000 records "marked" as deleted... [17:32] CardinalFang: you want to elaborate on your thoughts for delete propagation? [17:32] aquarius, we may not get undo support in couchdb soon. Perhaps we should plan a true expunging method. Along with deleted-p, add a deleted date. The desktopcouch service could sweep out all records that are more than N months old. With vigilance and timing, deleted records would disappear. [17:33] I'm genuinely curious [17:33] urbanape, I think there's a distinction between *actually deleted* (which is indicated by a_a.U1.deleted at the moment, and will eventually be indicated by the record not being there but being in the history), and Bindwood's notion of deletion-for-propagation (indicated by "deleted" at the top level) [17:33] I'm having difficulty articulating the precise difference, but I think they indicate different things [17:33] CardinalFang: I suggested to SteveA before he left that we might try a heuristic where each client that is involved in the process tags the record in Couch saying, "ACKD" [17:34] then, when all machines in the account have hit it, we can safely be sure it's been deleted from all instances in play. [17:34] you can't know how many machines there are, though [17:34] sure you can [17:34] or, at least, any one given machine can't know that "all the other machines have hit this record, so I can delete it" [17:34] they're the ones associated with the account. [17:35] aquarius: and if one of the machines died or deassociated then this record will stay forever [17:35] it wouldn't be any one of the machines/ [17:35] that only works in an Ubuntu One world, not a world with LAN pairing in it too... [17:35] urbanape, desktopcouch is bigger than Ubuntu One. [17:35] maybe we handle it centrally. [17:35] CardinalFang: yeah, but we can handle the cleanup for our users, and let other desktopcouch networks come up with their own policy. [17:36] what's wrong with differentiation along service lines? [17:36] because if I have all but one of my machines paired with U1 and one machine LAN-paired, that LAN-paired machine won't get to see the deleted record [17:36] so it'll put it back into couch, and then it'll appear everywhere else again [17:37] aquarius: I fail to see the distinction you mentioned previously between "really deleted" and "deleted for the purpose of propagation". Secondary machines still need to recognize a record that should be deleted locally. [17:38] aquarius: that case seems more than a little degenerate [17:38] Is that the same question? I thought aq had some idea about browser behavior only. [17:38] (as an aside: after a long holiday with no real adult conversation, I find this utterly fascinating) [17:39] the difference between really-deleted and deleted-for-propagation is that we're working around a deficiency in CouchDB's replication engine [17:39] because it doesn't propagate deletes. [17:39] CardinalFang: not sure. There are two things here: proper ways to mark records as deleted, considering that Couch DB record is canonical, so all clients have a go at deleting locally, and knowing when we can safely delete couch records "for real" [17:39] syncdaemon does, for example [17:40] well, we're making it propagate deletions. [17:40] aquarius: are you sure it does not? I remember killing the entries from the database and they did not return from the server afterwards... [17:40] o rly? [17:40] hm [17:40] urbanape, we're making it propagage an additional revision that has an element that says "ignore me please." [17:40] rtgz, urbanape, your two cases are diametrically opposite one another. They can't both be true :-) [17:41] delete_all_records.py.. need to locate this in the IRC logs [17:41] CardinalFang: yes, we're exploiting a new revision, but the upside is, we're propagating deletions. [17:42] a "deletion event" in _changes, for instance, would still be a document with a revision [17:42] it would just be a lot smaller. [17:42] s/would/could/ [17:42] urbanape, yes, as we have designed it for current usage. This is a hack. [17:42] thisfred rtagger: joshuahoover #474170 has a script to *permanently* delete all documents from a database. Use with appropriate caution. [17:42] ubottu: bug #474170 [17:42] Launchpad bug 474170 in desktopcouch "Deleted synchronized database always come back with the next sync" [Medium,Triaged] https://launchpad.net/bugs/474170 [17:43] CardinalFang: well, I'm gonna place it just on the side of "elegant" [17:44] including it in _changes feels right to me. Whether it's an annotation that makes the record grow, or it were better about "wipe out everything but its uuid and a note to the effect that clients should delete" isn't too important to me. [17:44] * rtgz starts liking trackerd once he has all IRC logs from #ubuntuone locally [17:44] It's a hack because if we remove the record from the database, then when we next ask a peer "I have set(a,b,d), what do you have?" and they say "Oh, I have c too!", we will still say "Send us C!" even though we removed C 10 minutes ago. [17:46] rtgz, log into couch! :) [17:46] I guess i'll need to check what happens to my bookmarks if i delete them in such way. The second couchdb is running in the VM so the effect should be seen shortly [17:47] It would be nicer if couchdb said instead, "Aw, I know of C and Idon't want it. KTHXBYE." [17:50] rtg@buzz:~/Downloads$ python delete_all_docs.py bookmarks => 1142 records permanently deleted, wow [17:51] Ubuntu One finished updating 0 files [17:52] awesome notification popped up :) [17:56] aquarius: it took me 10 minutes to realize what you told me :). Trackerd does not search couchdb, sorry ;( [17:57] rtgz, ah, not what I meant -- I meant, save irc logs into couch too, and then you can search it all there [17:58] aquarius: yep, xmpp conversations are ok, but IRC seem to require more attention and a test channel :) [17:59] aquarius: i mean xmpp MUC [17:59] CardinalFang: It's not just that, though! Couch not wanting it is not the same thing. In fact, it's not about what Couch wants. It's about what the user wants. Couch is acting as a proxy for the user. "The user wants this record deleted. So, delete it." [18:00] The vm just notified me that my files are up to date, then updated some more files and notified me again, repeated 3 times :-/ [18:00] we *need* to propagate the semantics of that intent, not just the record (heh) of its deletion once upon a time. [18:01] urbanape, I don't think we're talking on the same level. All I am saying is we have 1) ignore this forever and 2) expunge this information but get it back if someone else has it. [18:02] Is it only me or desktopcouch puts couchdb.html that contains an invalid port, on every system startup... [18:02] rtgz, CardinalFang may have already fixed that in trunk [18:03] I think I have, rtgz. [18:03] * rtgz is waiting for the bookmarks either to appear or to disappear... [18:04] rtgz: if you're using my PPA packaged bindwood, it won't push them again. [18:05] CardinalFang: are you talking about the notifications or couchdb.html? [18:05] it only pushes newer bookmarks than the last known last_modified bookmark on subsequent starts of Firefox. [18:05] urbanape: i am just waiting for the bookmarks to disappear from the second couchdb instance... [18:05] urbanape: or to appear again in the first one [18:06] rtgz, I think desktopcouch starting up is fixed in trunk. It fails to start the first time on some small fraction of machines. [18:06] It's a timing bug caused by a wrong assumption about pid file and socket availability. [18:07] CardinalFang: is it possible to teach couchdb to provide the required info itself and not to search through file handles? [18:08] rtgz: ah, between couches, gotcha. [18:08] rtgz, yes, in that it's open source and mutable and they might accept patches. [18:09] CardinalFang: 2 is only a concern in aquarius' degenerate use of the system. I think U1 can offer the ability to act as reliable steward for the registered machines. [18:09] If the user wants to entrust the replication to another machine outside that circle, they need to take additional steps to ensure that records are properly deleted when they should be. [18:09] there's a difference between "Ubuntu One is more reliable" and "if you don't use Ubuntu One you are *guaranteed* to be fucked by Bindwood" [18:09] the latter seems a bit unfair, since we're making Ubuntu One be a Bindwood dependency [18:10] how is that unfair? Use U1 in the manner intended, and you'll be fine. Get clever and you have to stay clever. [18:10] and I don't think we should do that [18:10] there is no way of being clever, though [18:11] if your definition of clever is "configure Bindwood correctly" then that's sorta OK. If your definition of clever is "never delete any bookmarks, or patch Bindwood" then that's unreasonable, I think [18:11] Let's pause a moment and decide if there's another way than assume a canonical listing of hosts. (har.) [18:12] no, when I'm talking clever, I'm talking about the guy who not only uses U1's desktop couch replication, but adds his own running on a slice into the mix. [18:12] CardinalFang: timestamping and acting after X months is just as surprising when the user starts up his long synced netbook six months later and now all these old bookmarks he doesn't care about get thrown back into the mix. [18:12] urbanape, yeah, but that's my point -- what you're suggesting is that LAN paired desktopcouches and Bindwood are fundamentally incompatible. [18:13] urbanape, that is: Bindwood depends on you having an Ubuntu One account [18:13] pause [18:13] not at all. [18:13] what I'm suggesting: [18:13] we use delete flags to propagate deletions to clients. [18:13] U1 offers a service whereby: [18:14] clients who's acked a deletion make note of themselves on the record somehow (hand wavy) [18:14] when all clients in an account have acked, delete the actual record in Couch. [18:14] urbanape, Using U1 as a list of hosts fails if any of 1) user discards computer and doesn't remove U1 token, 2) if user has any paired peers, 3) user has more than one service, 4) user has no service, 5) that Fedora guy ports to Fedora and it doesn't support the same host listing. [18:14] that can be done even in a LAN environment, just takes coordination. [18:14] urbanape, when you delete the record in couch, a LAN-paired server will just put it back, no? [18:15] at least, any LAN-paired server that hasn't seen it will just put it back [18:15] that's a degenerate case where a user has both: u1 and a LAN-paired server. That's clever, and they need to stay clever. [18:15] if a user is purely lan based, they'll have to roll their own solution. [18:15] yeah, but what I'm saying is: there is no way of them *being* clever. There's no way for them to avoid the situation where a LAN server puts their bookmarks back [18:15] hm, latest info from vm replication dates back to 2009-11-30... [18:15] which means that anyone who has a LAN-paired desktopcouch can't delete bookmarks [18:16] They don't have to be pure. They only need a single computer that U1 doesn't know about. [18:16] which means that Bindwood doesn't work properly if you have any LAN-paired servers [18:16] "doctor, it hurts when I do this." [18:16] it works if you only use LAN-paired servers [18:16] ahem. LAN pairing is a proper documented designed-in-from-the-beginning use of desktopcouch. It is not an extra bag hung on the side at the last minute. [18:17] How does it work if you only use LAN-paired servers? The deletion never happens, then. If you're OK with the deletion never happening, then why do we need it in an Ubuntu One world? [18:17] then keep the bloody records around and let the user delete them manually through futon when they're sure all their clients have dealt with them properly. [18:18] personally...that's what I think we should do, which is basically what we're doing at the moment, no? [18:18] then it works in whatever orgyistic haze the user has set up. [18:18] urbanape, Back to this -- "timestamping and acting after X months is just as surprising when the user starts up his long synced netbook six months later and now all these old bookmarks he doesn't care about get thrown back into the mix" [18:19] "Back into the mix" is still marked "ignore this -- it's called 'deleted'". [18:19] aquarius: yes, I was trying to address, for U1 users (see the channel we're in?) a means to automatically clean up. [18:19] * aquarius laughs [18:19] CardinalFang: not if the recently awoken client has that bookmark in play. [18:19] it'll go back into Couch as a new bookmark. [18:19] "In play"? [18:19] if it never got wind of the delted record, and that record has since been expunged. [18:20] I think clean-up isn't that important, esecially since at some point we'll have history, and then nothing ever gets cleaned up [18:20] urbanape, Oh, well it would get the new revision which clobbers it whenever it replicates to anywhere. [18:20] right, but client A, which six months ago deleted this bookmark would suddenly have it appear again. [18:21] Test completed: the real couchdb received 42 new bookmarks, the vm one remained with 1000+ bookmarks. Is it really making the same content available on all machines? [18:22] aquarius: I think you're right. It just feels needlessly cluttered and sending people to futon to clean up after themselves is kinda lackluster. [18:23] urbanape, Yes, certainly. That's the time out. What is reasonable delay between mark-as-deleted-so-it's-propagated and assume-everything-is-finished-and-expunge-old-records. [18:23] ? [18:23] inf - 1 [18:24] urbanape, I agree with you. This is why I think the real way to solve this is to actually delete the record (but keep it in history) and have the delete propagate, and have every bindwood check history before writing. That entirely solves the problem, but gives us the extra one of bindwood hammering the crap out of desktopcouch on startup [18:24] Dang. I was hoping for inf - 3. [18:24] That's sooner. [18:24] I'd still like to know how the presence of history is going to help. Presumably, this will require a full-on try-to-push-everything-on-every-start to check, "Should I still care about this one? This one? Have you got this one?" [18:25] aquarius: woops, was typing all that when you just said it. [18:25] that seems poo. [18:25] yep, that's exactly what I think should happen. If that's inefficient, we should think of a way of making it less so. [18:25] I can think of a few [18:25] what's our real concern here? [18:25] db bloat? [18:26] that's not *my* concern, but then I've got an 80GB hard drive. :) [18:26] I've got 500GB, here's a nickel. [18:26] :) [18:26] like, for example, have bindwood add a validator document that prevents pushing a bookmark if the identical one exists in history [18:26] so, one thing we could do. [18:26] does history only capture deletions? [18:27] urbanape, mine's SSD. If you've got a half-terabyte SSD it didn't cost no damned five cents :P [18:27] no, not SSD. [18:27] history is entirely theoretical at this point [18:27] aquarius: true, i got 1000 bookmarks and only 50 of them were not duplicates [18:27] the assumption is that it will capture every change [18:28] CardinalFang: is it possible to infer even non-U1 participants by finding out who all is in a replication network? [18:28] nope [18:28] well, that's dumb. [18:28] not without complicated collaboration between all the participants [18:28] It's complicated. Theoretically, yes. [18:28] pairing is not everyone-to-everyone [18:28] The coordination will have to be asynchronous. [18:29] And there is no obvious ringleader. [18:29] I mean, record deletion would be doable: a give server says "I will only mark this record as seen by me if it's already been seen by all my pairs" [18:29] We could elect one, but that might be a bad choice (e.g. offline often computer) [18:29]