| === jamesh changed the topic of #ubuntuone to: Have a question? Ask jamesh | https://one.ubuntu.com | https://launchpad.net/ubuntuone | Please honk if you want a music store | ||
| repete | Hi all | 08:42 |
|---|---|---|
| repete | Can anyone tell me how to force the syncing of file? | 08:42 |
| repete | Nautilus says it is synced, but I don't see it in the web UI | 08:43 |
| aquarius | hey repete. | 08:45 |
| aquarius | you can't actually *force* a file | 08:45 |
| repete | aquarius, hey, dude :-) | 08:45 |
| aquarius | when you say "nautilus says it's synced", what exactly do you mean there? that it has the emblem, or that you got a notification? | 08:46 |
| repete | aquarius, well there's two thing there... 1) Yes, nautilus has the green check mark icon next to the file, and 2) I got a notification that "1 file finished syncing", but that doesn't tell me which file | 08:47 |
| repete | aquarius, I added a directory, then two folders underneath, then added a file to each of those two folders | 08:47 |
| aquarius | the check marks are, as I understand it, not reliable at the moment (rtgz has written a patch for that, but I don't think it's released yet) | 08:47 |
| aquarius | do the logs show anything that looks like a failure? | 08:48 |
| repete | aquarius, not afaict | 08:49 |
| repete | aquarius, there is a notice that one of the files synced | 08:50 |
| repete | but nothing about the second | 08:50 |
| aquarius | strange. | 08:50 |
| aquarius | I...don't know, then, which is not very helpful, I know :( | 08:51 |
| repete | aquarius, well, when I say "force" what I mean is create the conditions under which U1 decides the file has changed and must be synced again | 08:51 |
| repete | aquarius, any idea there? | 08:51 |
| aquarius | when that happens to me (which it hasn't for a while, which is nice) I copy the file :) | 08:52 |
| repete | I already tried touch | 08:52 |
| rtgz | who what where when? | 08:52 |
| repete | create a copy and rename it? | 08:52 |
| jamesh | repete: I take it you tried reloading the web UI? | 08:53 |
| repete | jamesh, yes... | 08:53 |
| * rtgz waits 8 minutes until ubuntulog sends the log to the irclogs... | 08:53 | |
| * repete tries again | 08:53 | |
| jamesh | IIRC, change notification isn't fully implemented for the web UI | 08:53 |
| repete | Should I be looking at syncdaemon.log? | 08:54 |
| repete | yea, reloading the page doesn't work. :-/ | 08:55 |
| aquarius | rtgz, repete's got a file which isn't being synced to the web (and the emblem lies about it, which I think you've fixed but isn't released yet?) | 08:55 |
| jamesh | well, if you have another computer with the UbuntuOne client installed and configured, that would be a better indication that things are synchronising properly | 08:55 |
| repete | jamesh, unfortunately don't have that | 08:55 |
| rtgz | repete, u1sdtool --info $full_path_to_file - is there server-hash? and what is the filename? | 08:55 |
| repete | rtgz, that gives me a traceback :-/ | 08:57 |
| rtgz | aquarius, the emblems for regular files once dobey reviews the branch, then files are no longer utime()d and they are happy. | 08:57 |
| rtgz | repete, huh? Then it means that syncdaemon did not get to that file, i.e. 1) inotify dir handles limit reached, 2) syncdaemon crashed and does not want to recover | 08:58 |
| rtgz | repete, KeyError with the filename as the argument? | 08:58 |
| repete | rtgz, exactly | 08:58 |
| rtgz | repete, what is the file name, does it contain some accented characters? | 08:58 |
| repete | rtgz, no, but it contains underscores | 08:58 |
| rtgz | repete, underscores... and no colons, ":" ? | 08:58 |
| repete | though the other file that did sync also contains underscores | 08:59 |
| repete | no, none of those | 08:59 |
| rtgz | in Ubuntu One dir: find -type d | wc -l | 09:00 |
| rtgz | just to check how many directories you've got | 09:00 |
| rtgz | repete, ^ | 09:00 |
| repete | rtgz, 9 | 09:01 |
| rtgz | repete, not interesting. Okay, let me read the logs, so that I don't ask duplicating questions.. | 09:01 |
| rtgz | ah, not much to read :) | 09:03 |
| aquarius | rtgz, yeah, we'd only just started when you rocked up :) | 09:03 |
| rtgz | so, my first guess is to 1. save the logs from ~/.cache/ubuntuone/logs to some safe location. 2. u1sdtool -q, 3. u1sdtool -w, 4. Connect via applet, 5. Check that file is being uploaded | 09:04 |
| repete | rtgz, will do that, but how do I do #5? | 09:05 |
| rtgz | repete, however the logs in syncdaemon.log copied to paste.ubuntu.com might help as well to diagnose the real reason | 09:05 |
| rtgz | repete, u1sdtool --info $full_path_to_file | 09:05 |
| repete | ah... | 09:05 |
| repete | thx | 09:05 |
| rtgz | emblems... They give a false hope now :( | 09:07 |
| rtgz | repete, btw, u1sdtool -w will timeout with DBus error, this is "OK" for now | 09:09 |
| repete | rtgz, oh right. Ok. :-) | 09:09 |
| repete | rtgz, is that in the form of a traceback? | 09:09 |
| rtgz | repete, checking... | 09:10 |
| repete | rtgz, yea `u1sdtool --info ${full-path-to-file}` returns the same KeyError trackback | 09:11 |
| rtgz | repete, re: traceback: "Oops, an error ocurred: ... org.freedesktop.DBus.Error.NoReply:" | 09:12 |
| rtgz | rtgz, could you pleeeease share the file name with us? or privately, in order to check what might go wrong with the file name... Additionally, what locale are you using? | 09:13 |
| rtgz | repete, ^ | 09:13 |
| rtgz | rtgz, happy new year! | 09:13 |
| rtgz | repete, what version of u1 client are you using? just to try reproducing such condition? | 09:23 |
| repete | rtgz, 1.1.0+r294-0ubuntu1~ppa1~karmic | 09:26 |
| repete | rtgz, where do you want the logs? | 09:29 |
| repete | u1 share? ;-) | 09:29 |
| rtgz | repete, paste.ubuntu.com might be a better idea.. | 09:30 |
| aquarius | :) | 09:30 |
| rtgz | hm... U1 log sharing... | 09:30 |
| repete | rtgz, right. syncdaemon.log? | 09:30 |
| rtgz | we need group sharing! | 09:30 |
| rtgz | repete, yup | 09:30 |
| rtgz | however it looks like categories are not yet implemented for evolution backend .. | 09:32 |
| rtgz | summary: restart of syncdaemon log helped. The file got uploaded. no accented characters, colons or anything that might have prevented it from uploading | 10:06 |
| rtgz | the folder was initially called "untitled folder", then it was renamed to "v2.0", afterwards the file was put in v2.0 directory but it was not picked up by syncdaemon (inotify watcher not applied? ) | 10:09 |
| rtgz | reproduced | 10:17 |
| rtgz | ERROR: The path /home/rtg/Ubuntu One/untitled folder of this watch <Watch wd=42 mask=3064 auto_add=False proc_fun=None path=/home/rtg/Ubuntu One/untitled folder dir=True > must not be trusted anymore | 10:44 |
| rtgz | no, this error is not related, sorry | 10:45 |
| rtgz | Here's my log: http://paste.ubuntu.com/351172/ | 10:45 |
| repete | rtgz, thx for your help, btw | 10:55 |
| rtgz | repete, you are welcome, since there is virtually nothing done by me :) | 10:55 |
| === jamesh changed the topic of #ubuntuone to: https://one.ubuntu.com | https://launchpad.net/ubuntuone | Please honk if you want a music store | ||
| leny_ | The second computer (a Karmic UNR box) that I have connected to ubuntuone is (unlike the first, a desktop Karmic) not syncing evolution contacts. In the desktop-couch-replication.log is see multiple entries like this "2010-01-04 11:35:45,803 DEBUG static pairings are []" . Plus some starting and finishing replication messages. It appears I have a setup error but am unsure as to how to correct it. Help please? | 11:46 |
| rtgz | leny_, do you have access to that UNR box now? | 12:03 |
| leny_ | rtgz speaking from it | 12:03 |
| rtgz | leny_, ok, lets restart couchdb from terminal so that you will get a link to login to database frontend web page and check whether there are any contacts there. | 12:05 |
| rtgz | /usr/lib/desktopcouch/desktopcouch-stop | 12:05 |
| rtgz | /usr/lib/desktopcouch/desktopcouch-service | 12:05 |
| aquarius | desktopcouch-stop is a bit unreliable... | 12:06 |
| rtgz | (regular user, not root). after you launch desktopcouch-service, you will be given a link to html page. Open it in the browser and it should redirect you to futon (couchdb web frontend) running on localhost | 12:06 |
| rtgz | aquarius, erm... if it does not stop, then we will sigmurder it | 12:06 |
| aquarius | http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation/Troubleshooting describes the right way to do that :) | 12:07 |
| rtgz | leny_, yes, in case desktopcouch-stop is finished but ps auxw| grep desktop-couchdb still shows up, then kill it | 12:07 |
| rtgz | aquarius, hm, docs! | 12:08 |
| aquarius | rtgz, yes indeed. I wasn't sure if you knew about the DC docs | 12:08 |
| aquarius | http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation is being built up as I get more and more time | 12:08 |
| rtgz | aquarius, killall beam.smp... erm... Casual user might not have anything else running by erlang, right... | 12:09 |
| aquarius | rtgz, yeah. It's a bit dodgy, but I figure that if you're running any other erlang programs as your user account then, well, you'll know enough to look at that command and think: hm, I won't do that. | 12:10 |
| aquarius | desktopcouch-stop not working properly is most annoying. That needs fixing, which I shall discuss with thisfred and cardinalfang when they arrive ;) | 12:10 |
| leny_ | rtgz, had to kill the service. Now restarted and I am at the http://localhost:44173/_utils/ web page. | 12:12 |
| rtgz | leny_, ok, now browse to contacts db | 12:14 |
| rtgz | and see whether there are any contacts | 12:15 |
| leny_ | rtgz, I'm there. it's showing no entries | 12:15 |
| rtgz | ok. | 12:16 |
| rtgz | now shut down evolution completely | 12:16 |
| rtgz | evolution --force-shutdown | 12:16 |
| rtgz | and start evolution from terminal | 12:16 |
| * rtgz discovered that ASUS has also started their cloud file storage... | 12:17 | |
| rtgz | leny_, ^ (not about ASUS, but before that :) ) | 12:19 |
| leny_ | rtgz, done. I've discovered I was one "Design Documents" before on the browse page. I'm now on "All Documents" and it's showing the one locally entered record I have (to see if it would go up) | 12:20 |
| rtgz | leny_, so, is anything created in local evolution instance shows up in couchdb? | 12:33 |
| leny_ | Yup, but nothing goes between couchdb and ubuntuone in either direction. Though my other machine is fine. The failing machine is the second added to ubuntuone. I have prior to coming on irc done the restart described in http://www.freedesktop.org/wiki/Specifications/desktopcouch/Documentation/Troubleshooting | 12:45 |
| leny_ | Further I see the empty static pairings message unlike the log in Bug #471805 | 12:47 |
| ubottu | Launchpad bug 471805 in desktopcouch "Evolution contacts don't sync to Ubuntu One" [Undecided,Incomplete] https://launchpad.net/bugs/471805 | 12:47 |
| rtgz | leny_, management db, are there any records? | 12:49 |
| leny_ | rtgz, Yes a _design/get_records_and_type and a hex stamped record with a self_identity field in it. | 12:51 |
| * leny_ honks for a music store | 13:03 | |
| aquarius | leny_, working on it :P | 13:03 |
| jblount | leny_: :) | 13:03 |
| leny_ | rtgz, Don't know if it's related but the evolution terminal window has several copies of this message in the startup "** (evolution:3934): CRITICAL **: atk_object_set_name: assertion `name != NULL' failed" | 13:11 |
| rtgz | leny_, no, that's accessibiliti toolkit errors | 13:11 |
| rtgz | *accessibility | 13:12 |
| leny_ | rtgz, Thanks, thought I better mention it just in case | 13:12 |
| rtgz | leny_, so... when you start the evolution, you see the local entry in CouchDB addressbook, but that entry is not visible online, right? | 13:13 |
| rtgz | and you are able to create local entries, but they are not replicated | 13:13 |
| aquarius | leny_, you don't have an entry in desktopcouch to pair it with Ubuntu One. The applet is meant to put that in, and it must have failed before. If you restart the applet, it should be added; try killing the applet (killall ubuntuone-client-applet) and then restarting it (Applications > Internet > Ubuntu One) | 13:15 |
| aquarius | and then look in your desktopcouch management database again; there should then be a new record, relating to Ubuntu One. | 13:15 |
| rtgz | aquarius, you mean the record_type .../paired_server ? | 13:17 |
| aquarius | rtgz, yep. The applet, when it starts up, looks to see if desktopcouch is paired with U1, and if it isn't, the applet adds a pairing record for U1 | 13:18 |
| aquarius | rtgz, but from the sound of it, leny_'s desktopcouch was being weird, so the applet may have tried and failed to add the pairing record | 13:18 |
| leny_ | aquarius / rtgz, now have 4 records in management db. Inclusing design and what looks like the pairing details for ubuntuone . Waiting 10 minutes for a sync | 13:25 |
| aquarius | haha! excellent. | 13:25 |
| rtgz | leny_, awesome. Ok, aquarius, is there any bug report describing such "unable to add record to db, and nobody cares, so act happily" condition? | 13:29 |
| aquarius | rtgz, there isn't, at the moment, so adding one would be good. (Part of the reason is that it's not clear what to actually do in that situation; telling the user isn't useful, since they don't know how to fix it, nor should they) | 13:30 |
| aquarius | unless CardinalFang knows differently and there already is a bug report | 13:31 |
| rtgz | "There appear to be a problem with Ubuntu One server pairing sequence. You might want to [try this task again] or gather required info using [apport]" | 13:32 |
| leny_ | rtgz, aquarius, Sync HAS taken place, records now in Evolution. Many thanks | 13:32 |
| rtgz | but applet sitting there showing "me is connected!" when a part of the system is broken is... misleading... Much like the emblems :)... dobey dobey dobey :) | 13:33 |
| aquarius | rtgz, ah, but you can't try the task again, since you can't manually trigger the add-a-pairing-record sequence, and if it hasn't worked then clearly there's a bug somewhere else preventing it (like, desktopcouch was unresponsive). Fixing *that* bug should stop the problem | 13:34 |
| leny_ | A footnote: As well as doing the killall mentioned I killed this as well /usr/bin/python /usr/lib/ubuntuone-client/ubuntuone-syncdaemon | 13:38 |
| rtgz | aquarius, why can't I trigger the "PAIR NOW!" sequence? | 13:41 |
| aquarius | rtgz, because you shouldn't ever, ever have to manually trigger it, therefore manual triggering isn't exposed | 13:41 |
| aquarius | rtgz, if you want to, you can run desktopcouch-pair, in the desktopcouch-tools package, to manually add an Ubuntu One pairing record | 13:41 |
| aquarius | (or to pair with a LAN desktopcouch) | 13:42 |
| rtgz | btw, is there a dedicated dc irc room? | 13:45 |
| rtgz | I've got some questions regarding record updates... | 13:45 |
| thisfred | rtgz, there is, but more people are here | 13:46 |
| thisfred | rtgz: #desktopcouch currently has me, and __lucio__ who are both here as well\ | 13:47 |
| thisfred | and this channel is fine for discussing all things d-c | 13:47 |
| statik | hi thisfred, hows life? | 13:50 |
| thisfred | hey statik, pretty good, actually | 13:52 |
| thisfred | how are you? | 13:52 |
| CardinalFang | rtgz, the application should treat it like any other IO error. What does it do if the disk is read-only? Something like that for problems with desktopcouch. | 13:52 |
| statik | thisfred, i'm happy and more dangerous than ever | 13:53 |
| thisfred | a powerful combination ;) | 13:53 |
| statik | thisfred, could you look at https://answers.launchpad.net/ubuntuone-servers/+question/96145 and tell me if I need to be worried? | 13:53 |
| thisfred | on it | 13:54 |
| urbanape | aquarius: had a really crazy set of revelations about the manifest stuff for Bindwood last week. | 13:56 |
| thisfred | statik: hmm, I think we'll need more infor for that one. I don't know a lot about the web ui side of things. It may be an underlying couchdb problem, but I'll need to look at the logs. | 13:56 |
| aquarius | urbanape, oh? do tell? (HNY btw!) | 13:56 |
| thisfred | statik: in the meantime, teknico might have an idea | 13:57 |
| aquarius | thisfred, there is currently a problem with notes and couch; rodrigo_1 and, I think, CardinalFang are looking at it | 13:57 |
| thisfred | aquarius: aha, way ahead of me | 13:57 |
| * rtgz is holding a big banner /[Say no HTML for Tomboy Notes today!]\ | 14:00 | |
| urbanape | aquarius: I wrote it up as a rambling conversation with myself. I'll send it along. | 14:01 |
| statik | urbanape, you write rambling conversations with yourself too? i feel better knowing i'm not alone ;) | 14:02 |
| urbanape | statik: well, it started as a straightforward "let's get out what we have left to do" and then I started questioning that, and it turned into a bunch of Q: and A: paragraphs. | 14:04 |
| urbanape | maybe I'll send it to the internal list. | 14:04 |
| urbanape | anyway, the main upshot is that the manifest isn't necessary *except* to support the web ui. | 14:04 |
| urbanape | so long as we add a bit of hackery to the records' schema | 14:05 |
| === rodrigo_1 is now known as rodrigo_ | ||
| rodrigo_ | hey statik | 14:17 |
| statik | hola rodrigo_, did you have a fun holiday? | 14:18 |
| rodrigo_ | statik: yeah, lots of fun :-) | 14:18 |
| rodrigo_ | statik: when you have time, could you re-review https://code.edge.launchpad.net/~rodrigo-moya/libubuntuone/bring-music-store-live/+merge/16426 please? | 14:18 |
| rodrigo_ | statik: and you? or you did not take vacation? | 14:19 |
| statik | rodrigo_, I did! it was great. wrote a jabber bot and a weird django file downloading experimental thing, and read lots of books and ate so much delicious food | 14:20 |
| rodrigo_ | statik: oh, more productive than me then, just ate delicious food :) | 14:20 |
| statik | rodrigo_, I still get u1-marshal.h not being created | 14:21 |
| statik | i'm on revno 8 | 14:21 |
| statik | i made a totally clean branch, ran ./autogen.sh and didn't see errors, then ran make | 14:21 |
| rodrigo_ | statik: and you have glib-genmarshal installed, right? | 14:22 |
| statik | yep, when i cd into libubuntuone and run make u1-marshal.h that works fine, and then the compile completes successfully | 14:22 |
| urbanape | thisfred: are you a guru on the _changes feed? | 14:22 |
| rodrigo_ | statik: weird, it works for me on a clean branch without hassle | 14:23 |
| rodrigo_ | statik: the rules in the Makefile.am seem to be ok | 14:23 |
| aquarius | thisfred, CardinalFang, urbanape: some desktopcouch things have come up over the break, which I'd like to lay out for you if you're all available at some point today | 14:23 |
| urbanape | I'm up for it | 14:24 |
| thisfred | urbanape: somewhere between guru and clueless, I'd say | 14:24 |
| urbanape | we're switching to MySQL? | 14:24 |
| aquarius | urbanape, nah, just csv files | 14:24 |
| thisfred | aquarius: sounds good | 14:24 |
| urbanape | w00t! | 14:24 |
| thisfred | aquarius: ZODB ? :) | 14:24 |
| * aquarius shoots thisfred. In the face | 14:24 | |
| statik | believe it or not MySQL has a csv engine | 14:24 |
| rtgz | aquarius, raw random access block devices | 14:24 |
| rtgz | the real black box... | 14:24 |
| thisfred | aquarius: tsss, the ZODB is awesome. And quite similar to couchdb in some respects | 14:25 |
| urbanape | thisfred: I had been asking CardinalFang over the break, and he was pretty sure it didn't exist, but I thought I'd ask you: do you know if you can get field-level granularity in the _changes feed to see which fields have changed in a given revision? | 14:25 |
| thisfred | it's just the 12 million zope layers on top that vary in usability | 14:25 |
| aquarius | rtgz, you implement oauth as a kernel module and I'm all over it ;) | 14:25 |
| thisfred | urbanape: I too am pretty sure you can't | 14:25 |
| thisfred | urbanape: but let me triple check | 14:25 |
| aquarius | urbanape, nope, you can't. | 14:26 |
| statik | rodrigo_, i just approved the branch. when do we get packages for this uploaded to ubuntu? | 14:26 |
| urbanape | this book: http://books.couchdb.org/relax/reference/change-notifications talks about the style=all_docs option to "get more revision and conflict information in the changes array for each result row." | 14:26 |
| aquarius | the couch people are Unkeen on the idea of telling you what's changed. you're supposed to hit the document. annoying but true. | 14:26 |
| rodrigo_ | statik: as soon as I get this and another branch merged | 14:26 |
| urbanape | what additional info does that give you? Nothing that I've been able to tell... | 14:26 |
| rtgz | aquarius, and filesharing via DRBD.. | 14:26 |
| urbanape | aquarius: but using documents as the change message is pretty lousy. | 14:26 |
| rodrigo_ | statik: you have superpowers to merge the branches in tarmac, right? | 14:27 |
| urbanape | aquarius: did you read my ramble? | 14:27 |
| aquarius | urbanape, I did. I am mulling it over to be sure that I understand it | 14:28 |
| urbanape | so, alternately, we could make Bindwood always stamp the bookmark's current location on any document that it sends back to Couch (which is somewhat counter to the idea that we're only observing granular changes locally) | 14:29 |
| statik | rodrigo_: i'm running tarmac on libubuntuone now | 14:29 |
| urbanape | and always update every field when we bring in a changed bookmark from Couch. | 14:29 |
| rodrigo_ | statik: could you then please merge https://code.edge.launchpad.net/~rodrigo-moya/libubuntuone/bring-music-store-live/+merge/16426 and https://code.edge.launchpad.net/~rodrigo-moya/libubuntuone/python-bindings/+merge/16543 ? | 14:29 |
| rodrigo_ | statik: cool, thanks | 14:29 |
| urbanape | I don't mind my .application_annotations.field_changes notion, but I wish there were a better place for that annotation to go (like on the revision itself, somehow) | 14:30 |
| rodrigo_ | statik: btw, in one of the few productive moments I had while on vacation, I was thinking if it would make sense to merge libubuntuone into ubuntuone-client? | 14:30 |
| rodrigo_ | dobey: what do you think? | 14:31 |
| thisfred | woohoo, nostalgy for TB3 is out. This will make email catch up about a gazillion times faster and less frustrating | 14:33 |
| rodrigo_ | TB3? | 14:34 |
| rodrigo_ | ah thunderbird? | 14:34 |
| thisfred | thunderbird, sry | 14:34 |
| rodrigo_ | then, nostalgy? :D | 14:34 |
| urbanape | sent it all to the list. thisfred and CardinalFang: I'd appreciate your thoughts as well. | 14:34 |
| thisfred | urbanape: will look at it as soon as I get there | 14:34 |
| urbanape | danke | 14:35 |
| urbanape | statik: yeah, I find I actually get a lot more written when I pretend it's a conversation. I get some structure out of it, and I can explore all the aspects of what I'm talking about. | 14:36 |
| urbanape | (or think I'm talking about) | 14:37 |
| statik | hey aquarius, rodrigo_: are you guys available for a phone chat about the music store in 1 hour and 22 minutes? | 14:38 |
| aquarius | yep | 14:39 |
| dobey | rodrigo_: i think my brain is frozen :) | 14:40 |
| jcastro | jblount: when you're around I'll need the graphic for the forum badge. | 14:42 |
| rodrigo_ | statik: yeah | 14:42 |
| rodrigo_ | dobey: too much snow? :D | 14:43 |
| dobey | rodrigo_: about 2 hours of sleep last night, thanks to having to take the early flight | 14:43 |
| urbanape | dobey: early flight? where you at? | 14:44 |
| dobey | urbanape: burlington.ma.us | 14:44 |
| urbanape | gonna get your ski on? | 14:45 |
| urbanape | ah, I was thinking of burlington, vt | 14:45 |
| dobey | not really anywhere to ski here... and i hate snow anyway | 14:45 |
| rodrigo_ | dobey only skies on sand :D | 14:48 |
| statik | i always pictured dobey as more of a wingsuit man http://en.wikipedia.org/wiki/Wingsuit_flying | 14:49 |
| dobey | if i were going to ski, it would probably be on water | 14:49 |
| dobey | liquid water | 14:49 |
| rtgz | web guis: http://yui.yahooapis.com/2.8.0r4/build/connection/connection-min.js is loaded by /notes/new from https ui. Causes firefox to drop "Secure" status for the page | 14:51 |
| aquarius | rodrigo_, I have updated https://blueprints.edge.launchpad.net/ubuntu/+spec/lucid-ubuntu-one-musicstore so do please correct me if I've missed anything :) | 14:51 |
| rodrigo_ | ok | 14:52 |
| dobey | i think hotels use a different metric for "speed" with regards to internet | 14:53 |
| rodrigo_ | statik: ah, found the u1-marshal.h problem on another clean branch, will submit a fix with the debian package one | 14:55 |
| statik | rodrigo_, great! are you including the debian/ dir with the branch? i've seen that discouraged generally, but i've also seen people recently on planet ubuntu saying thats a frustrating rule to have | 14:56 |
| rodrigo_ | statik: hmm, I usually don't include the debian/ dir int he code branch, so I guess I'll do it on a separate package branch then? | 14:57 |
| statik | the general practice seems to be doing a release tarball without the debian/ dir, yeah | 14:57 |
| statik | i'm not 100% sure how to bootstrap the packaging branch to work with the UDD branches, james westby would know for sure | 14:58 |
| dobey | distribution-specific things in tarballs is generally frowned upon upstream | 14:58 |
| 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 |
| dobey | rodrigo_: not sure about merging libubuntuone | 15:00 |
| rodrigo_ | statik: well, I wouldn't include the debian/ dir in the tarball, just in the source branch | 15:00 |
| rodrigo_ | dobey: well, the nautilus plugin would use the contacts-picker widget, that's why I thought about it | 15:01 |
| rodrigo_ | dobey: and also, we could include other stuff, I guess | 15:01 |
| rodrigo_ | dobey: for packaging, it would be on a separate package though | 15:01 |
| dobey | debian dir in code branches is a pain to maintain | 15:02 |
| rodrigo_ | statik: https://code.edge.launchpad.net/~rodrigo-moya/libubuntuone/fix-marshal-generation/+merge/16783 | 15:04 |
| rodrigo_ | statik: can you try it please? | 15:04 |
| statik | rodrigo_, this is a good page to read https://wiki.ubuntu.com/DistributedDevelopment/ | 15:04 |
| statik | yep, I'll try it now | 15:04 |
| rodrigo_ | statik: ok, reading | 15:05 |
| rtgz | btw, is there any info on what is causing the global outage of note sync for all u1 users? | 15:05 |
| rodrigo_ | rtgz: yes, a problem with _rev AFAIK | 15:06 |
| dobey | rodrigo_: packaging is irrelevant if we merge them. library would be separate binary packages anyway | 15:07 |
| rodrigo_ | dobey: yeah | 15:07 |
| rtgz | any ETA? Cause this is a substantial part of life that UbuntuOne is aimed to backup | 15:07 |
| statik | rodrigo_, it works! i approved the merge, if you set the commit message i'll run tarmac | 15:07 |
| rodrigo_ | statik: done | 15:08 |
| rodrigo_ | dobey: well, the thing is I'm about to start packaging libubuntuone, so either I do it on a separate package branch, or merge it with u1-client and add needed stuff to u1-client's packaging branch | 15:09 |
| rodrigo_ | dobey: that would make it easier, since we won't have to run over the approval process for new packages | 15:10 |
| rodrigo_ | dobey: so, what do you think, shall I merge it? | 15:10 |
| dobey | CardinalFang: you need to be more proactive about that i think :) | 15:10 |
| CardinalFang | I guess so. | 15:11 |
| CardinalFang | Fear, Fire, Foes, Awake! | 15:11 |
| CardinalFang | ...maybe that only works for Hobbits. | 15:12 |
| rodrigo_ | me :D | 15:12 |
| CardinalFang | me | 15:12 |
| rtgz | me? | 15:13 |
| CardinalFang | Are we still having these? Desktop+ MEETING BEGINS. Say 'me' to claim a slice of the stand-up meeting, then take your turn by saying DONE/TODO/BLOCKED. | 15:13 |
| aquarius | me | 15:13 |
| dobey | not me, upstream connection is too slow to type with :( | 15:14 |
| rtgz | dobey, internets is slow today here as well :( | 15:14 |
| rtgz | the whole world is checking their emails, downloads updates and visits their social networking sites | 15:14 |
| dobey | maybe me | 15:15 |
| urbanape | me | 15:15 |
| dobey | rodrigo_: i think it should probably stay separate. would arther it be separate, than decide to move it back out later. :) | 15:16 |
| rodrigo_ | dobey: well, nautilus plugin is the main user of the library | 15:16 |
| rodrigo_ | s/is/will be | 15:16 |
| dobey | rodrigo_: music store | 15:17 |
| dobey | rodrigo_: and ideally third party apps :) | 15:18 |
| rodrigo_ | dobey: right, but part of u1 still | 15:18 |
| rodrigo_ | dobey: I really don't see a reason to have it separate really | 15:18 |
| dobey | yes but it's a separate projects | 15:18 |
| dobey | well we might add more to it later | 15:18 |
| rodrigo_ | given that we have, in u1-client, several subprojects | 15:18 |
| rodrigo_ | dobey: but all related to u1 :D | 15:18 |
| dobey | well all of gnome-foo is related to gnome... | 15:19 |
| rodrigo_ | so, do we start the standup? | 15:19 |
| dobey | please | 15:19 |
| dobey | before i can't type again | 15:19 |
| dobey | rodrigo_: go :) | 15:20 |
| rodrigo_ | • DONE: Vacation. Mail/music store catching up. Merge 2 libubuntuone branches. Started work on debian package for libubuntuone. Fixed marshalers generation code | 15:20 |
| 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? Look at Canola. Add envvar to override music store default location | 15:20 |
| rodrigo_ | • BLOCKED: no | 15:20 |
| rodrigo_ | CardinalFang: go | 15:20 |
| dobey | Chipaca is going through immigration right now i suspect :) | 15:21 |
| CardinalFang | DONE: Gregorian new year. | 15:21 |
| CardinalFang | TODO: Help educating Tomboy to write with revisions to desktopcouch. Finally make boss happy and put work ideas in bugs and blueprints. | 15:21 |
| CardinalFang | BLOCKED: Nein. | 15:21 |
| CardinalFang | rtgz, if you have something to say... | 15:21 |
| rtgz | DONE: Some nautilus module debugging, corrected weak ref notify to be removed on module shutdown, waiting for merge. Standalone note sync script for GNote/Tomboy to local CouchDB sync. | 15:21 |
| rtgz | TODO: Get a real job, update diagnose client with something, | 15:21 |
| rtgz | BLOCKED: Sick | 15:21 |
| rtgz | aquarius, to infinity and beyond! | 15:21 |
| aquarius | ⚀ DONE: submitted initial fake music store and music store for review; worked out file delivery API; specced file delivery; consumed the European mince pie mountain | 15:21 |
| aquarius | ⚁ TODO: package rhythmbox plugin; work out why decorators don't work on HttpResponseRedirects; allow OAuth to web UI; make music store views better; make workitems of outstanding todo items; make tomboy first-sync experience nicer | 15:21 |
| aquarius | ⚂ BLOCKED: | 15:21 |
| aquarius | dobey, you're up | 15:21 |
| dobey | ☺ DONE: Reviews, Fixed #485824, Fixed #499850, Bug triage, Moved logging config to a separate generated conf file | 15:23 |
| dobey | ☹ TODO: More new UI code, Lean training, | 15:23 |
| dobey | ☹ BLCK: None. | 15:23 |
| dobey | urbanape, jblount: somebody pick up the phone :) | 15:24 |
| urbanape | DONE: Made some great (on paper) progress on Bindwood, ready to be implemented. | 15:24 |
| urbanape | TODO: get 'er done | 15:24 |
| urbanape | BLOCK: None | 15:24 |
| urbanape | jblount: europe | 15:24 |
| dobey | brb | 15:27 |
| dobey | hrmm, i need to find me some food | 15:34 |
| * rtgz found that one line merges tend to get better review approval than multi-line :) | 15:35 | |
| dobey | one line changes tend to be easier to review | 15:35 |
| aquarius | - UBUNTUONE_SERVER_URL = "https://one.ubuntu.com" | 15:38 |
| aquarius | + UBUNTUONE_SERVER_URL = "http://yepishev.name" | 15:38 |
| aquarius | :-) | 15:38 |
| CardinalFang | Not easier to accept, aquarius . | 15:38 |
| * aquarius grins | 15:38 | |
| CardinalFang | Just review. | 15:38 |
| rtgz_ | aquarius, I have been thinking about registering that domain for 3 years... I guess I know what I'll do with it now :) | 15:42 |
| * aquarius grins | 15:42 | |
| rtgz_ | _very_ personal cloud | 15:42 |
| dobey | i had a cloud once, then it evaporated | 15:43 |
| rtgz_ | web ui people, please please please implement file searching... | 15:46 |
| * rtgz_ emitted too much "please please please" feature request today, shutting down | 15:47 | |
| dobey | filename searching, or file contents search? | 15:48 |
| rtgz_ | dobey, file name for now, content search is something that will make u1 web ui really stand out. | 15:51 |
| * rtgz_ tested ASUS WebStorage | 15:51 | |
| * rtgz_ did not like the UI, it is scaaary | 15:51 | |
| dobey | well, it's a privacy issue unfortunately | 15:52 |
| dobey | is launchpad really slow right now? | 15:58 |
| rtgz_ | and now the final q for the web guys (no please please please) - why are the links pointing 1) to _new window, 2) the URL does not contain the filename so that when new tab IS opened, the original filename becames visible only on download | 16:00 |
| aquarius | statik, rodrigo_? | 16:02 |
| rodrigo_ | aquarius: ready | 16:03 |
| statik | rtgz_, I don't know why they are pointing to _new, thats annoying. The URL doesn't have the filename because of addressing, but we could stick the filename in and just ignore it in the download server, that would be more userfriendly. Should probably also add the filename in a tooltip. | 16:04 |
| jblount | rtgz_: I think they point to _new because those links were opening the file (instead of downloading it). This is a bug. | 16:07 |
| jblount | Oh, and sorry I missed the standup. I mis-judged how long my run would take me after taking two weeks off :( | 16:09 |
| jblount | DONE: Holiday, Email triage | 16:09 |
| jblount | TODO: Public file links! | 16:09 |
| jblount | BLOCKED: Nope | 16:09 |
| thisfred | urbanape: I'm having trouble understanding the email, which likely means I'll have to read it more thoroughly, but I still wonder if there isn't a simpler, stupider solution to the problem. As an analogy, over the holidays, I worked on a pet project that deals with audio files, and I kept searching for a way to fingerprint just the audio content of a file, mostly so I could see if it was the same file when it was moved, and/or w | 16:11 |
| thisfred | hen its id3 tags were modified. | 16:11 |
| thisfred | urbanape: in the end, it turns out that this is almost impossibly hard | 16:12 |
| rtgz_ | statik, _new != _blank, re- filename appended to the download hash - agree | 16:12 |
| thisfred | and instead, I gave up on the first part, and just use the full path to the file as an id everywhere | 16:12 |
| thisfred | which gave me everything else I needed | 16:12 |
| thisfred | and it turns out *I* at least, don't move my mp3s around all that much | 16:13 |
| rtgz_ | re: music store - ogg/mp3/mp3-only/ogg-only/DRM ? | 16:14 |
| thisfred | rtgz_: I think mp3 no DRM | 16:14 |
| thisfred | urbanape: I wonder if there is some way to do the same for the bookmarks: using the "path" as (part of) the couchdb id | 16:15 |
| rtgz_ | htere was an earlier discussion about syncdaemon not picking up the files when they are put into dirs. I managed to reproduce that, anybody interested? | 16:18 |
| rtgz_ | with TRACE log level | 16:19 |
| urbanape | thisfred: but moving a bookmark (changing its path) doesn't change *the bookmark* | 16:23 |
| urbanape | they're orthagonal aspects. Its location is metadata, not the data itself. | 16:24 |
| urbanape | I'm not at all surprised that it's hard to read. It was mostly just a stream of consciousness kind of thing. | 16:24 |
| urbanape | but I wanted to get some feedback from other Couch-y types. | 16:25 |
| dobey | rtgz_: i don't think record labels generally release music as flac/ogg/etc... mp3 is the standard | 16:25 |
| thisfred | urbanape: Of course in an ideal world, content and metadata of this kind would be cleanly separated, but to couchdb, it's all data | 16:26 |
| dobey | man it is cold in here | 16:26 |
| urbanape | thisfred: sure, which is why I am proposing this kind of hackishness. | 16:28 |
| thisfred | urbanape: also, in any other database system, they will tell you not to use semantically meaningful ids | 16:28 |
| urbanape | the ids I'm proposing aren't semantically meaningful | 16:28 |
| thisfred | urbanape: rereading | 16:28 |
| thisfred | urbanape: yeah I know, I'm saying, in couchdb, it seems to be fine to use such ids | 16:28 |
| urbanape | I'm suggesting that instead of using Couch's generated ids, and annotating the record with a locally produced uuid, we just use the uuid as the id and be done with it. | 16:28 |
| urbanape | thisfred: ah | 16:28 |
| urbanape | yes, it does turn some traditional db conventions on their ears | 16:29 |
| thisfred | note that it may not be the solution you're looking for at all, but I'm saying that challenging almost all your assumptions sometimes gets you a very simple 99% (i.e. good enough) solution in couchdb | 16:30 |
| thisfred | of course that's not a mode one can work in all the time | 16:32 |
| urbanape | okay, so partly, I'm also looking for affirmation that this might not necessarily be "hackish" but could, in fact, be a conventional way of doing things in the CouchDB world. | 16:33 |
| urbanape | since we have to rely on the document being the message, and all. | 16:33 |
| thisfred | urbanape: On second reading I'm thinking that yes, it may be the couchish way | 16:34 |
| thisfred | I'm not worried about the upgrade that much, if we can generate the manifest for a new user, we can do it for existing users too, right? | 16:35 |
| thisfred | urbanape: yeah, I think this is a good idea. Possibly even having 1 manifest per folder. In couchdb splitting things up into multiple documents makes them less fragile often | 16:36 |
| thisfred | hmm, I'm not sure I'm getting it yet | 16:38 |
| thisfred | what is the manifest? | 16:38 |
| thisfred | urbanape: Is it not a couchdb document in your vision? | 16:39 |
| thisfred | I would make it one, but rather than have manifest, have a bookmark and a folder record type | 16:39 |
| thisfred | folder record types, have just one field: contents, which is a list of ids (of folders and bookmarks) | 16:40 |
| thisfred | or have I now unsolved the actual problem? | 16:40 |
| urbanape | thisfred: so, the manifest as originally envisioned is a single JSON doc that represents the entire bookmarks tree, but only in terms of the structure. | 16:40 |
| urbanape | a tree of uuid nodes | 16:40 |
| thisfred | ah ok, so I got that right | 16:40 |
| thisfred | having multiple folder documents instead, and the tree structure implicit, makes the chance of conflicts smaller | 16:41 |
| urbanape | I can see that, I guess. | 16:42 |
| thisfred | I'm just thinking out loud, so by no means I'm saying this is the one solution to rule them all and in darkness bind them | 16:42 |
| urbanape | the problem I uncovered (I think) is that for Bindwood clients, the manifest is useless, but it seems essential for decent responsiveness on the web ui (where we don't want to seek to rev 0 and walk the entire history) | 16:42 |
| urbanape | sure | 16:42 |
| urbanape | the upgrade or migration is just about the people who've been using it to date. "Blow away your database and start over" is a solution I'd like to avoid. | 16:44 |
| thisfred | urbanape: right, so writing a view that reproduces the tree should not be that hard | 16:44 |
| thisfred | urbanape: right, but since they have a folder structure in their firefox, we can generate the tree from that | 16:44 |
| thisfred | and hopefully not nuke their other clients | 16:44 |
| urbanape | I think my prediliction had been towards fewer document types in the database: records (bookmarks and folders) and ancillary material (manifests and design views) | 16:44 |
| urbanape | thisfred: yes, but there will need to be a migration step. The structure can always be recreated, so long as they're doing it from the "canonical" location | 16:45 |
| thisfred | I agree with non-proliferation of document types | 16:45 |
| urbanape | (since if you currently use Bindwood, your secondary machines won't necessarily reflect your organization) | 16:45 |
| urbanape | thisfred: and that's where I came up with one JSON doc for the entire manifest tree. | 16:46 |
| urbanape | but I'm open-minded. | 16:46 |
| dobey | brb | 16:46 |
| thisfred | urbanape: I would think folders and bookmarks would do it, what does the manifest add that folders can't do? Or do we need a root that isn't a folder? | 16:46 |
| urbanape | so, in the case of normal Bindwood clients, each maintains its own state of the last known rev it's seen. | 16:47 |
| thisfred | aquarius: feel free to weigh in, since you're quite good at blowing holes in my theories ;) | 16:47 |
| urbanape | the web ui won't have that luxury (without resorting to HTML storage or something) | 16:47 |
| urbanape | so we'll want something to short circuit the "go to rev 0 and walk the history to arrange everything as it should be" | 16:48 |
| thisfred | urbanape: but will the web ui need to? the web ui doesn't have the problem that it stores things in two places, couchdb will just *be* it's storage | 16:48 |
| urbanape | walking all the folders is closer to that in my mind than "get this one document" | 16:48 |
| thisfred | urbanape: so it won't need to track changes at all | 16:48 |
| urbanape | thisfred: that's true | 16:48 |
| urbanape | we want our web uis to be responsive and "real time" though, don't we? | 16:49 |
| thisfred | and it may be possible to write a single smart view that gives you the tree | 16:49 |
| urbanape | I imagined the web ui would also be tracking _changes after it built up the initial view | 16:49 |
| urbanape | but that would be nicer, too. | 16:49 |
| thisfred | you mean constant ajax updates? Could work, but it could also just ask the database for the view again | 16:50 |
| urbanape | hm. okay, but moving from the manifest to each folder record maintaining a list of its children still means multiple records getting updated if a bookmark is moved from, say, one folder to another. | 16:50 |
| urbanape | rather than just the bookmark and the manifest being updated. | 16:50 |
| thisfred | urbanape: yes, you'd be updating the two folder documents | 16:50 |
| thisfred | wait, why would you need to update both? | 16:51 |
| urbanape | because both of their children lists would change | 16:51 |
| thisfred | do you have links going both ways? | 16:51 |
| thisfred | no I mean in your scenario | 16:51 |
| urbanape | want to move this to voice? | 16:51 |
| thisfred | if you move the document from one folder to another, that would only mean an update to the manifest or not? | 16:52 |
| thisfred | urbanape: sure, but in that case I definitely want aquarius in too :) | 16:52 |
| urbanape | in my proposed scenario, moving any bookmark anywhere entails updating two documents: the bookmark itself with its new location (parent uuid and index) and the manifest | 16:53 |
| aquarius | hang on, just got off a phone call | 16:53 |
| thisfred | hmm, I would keep the location information in one place only | 16:53 |
| aquarius | give me five mins to review the scrollback and get tea | 16:53 |
| thisfred | right | 16:53 |
| thisfred | awesome | 16:53 |
| urbanape | the manifest remains a static document representing the current canonical structure. It would be updated after every add, delete, and move (but not on an internal bookmark change (title, uri, &c)) | 16:53 |
| thisfred | right | 16:53 |
| thisfred | so a bookmark document itself would not know from location | 16:54 |
| thisfred | or need to | 16:54 |
| urbanape | what you proposed would also update two documents: the old parent and the new parent | 16:54 |
| thisfred | right | 16:54 |
| urbanape | but not the bookmark itself | 16:54 |
| thisfred | and that's fine | 16:54 |
| urbanape | yeah. | 16:54 |
| urbanape | and in the case of simply reordering a folder, only one document | 16:54 |
| thisfred | updating two documents is nothing. I'm just saying with the manifest it could be one | 16:54 |
| urbanape | See, this is what I missed working this out alone. | 16:55 |
| thisfred | but the benefits of having it be multiple documents outweighs the efficency of updating just one IMO | 16:55 |
| urbanape | I'm glad I came to my epiphany before I got too much written with JSON diffing libraries, though. Lord what a pain. | 16:55 |
| urbanape | I'm liking this approach. | 16:55 |
| urbanape | and we still wouldn't need the manifest, even for the web ui. | 16:56 |
| thisfred | ok, good, then there's a chance aquarius won't say bollocks | 16:56 |
| dobey | bbiab, lunch and mobility | 16:56 |
| urbanape | okay, so, since documents are the change medium | 16:56 |
| urbanape | a bookmark move is represented by (at most) two folder revisions in the _changes feed | 16:57 |
| urbanape | a delete and a create | 16:57 |
| urbanape | I wonder if we'll want to encapsulate that somehow in a higher-level language. | 16:57 |
| urbanape | that the client can interpret | 16:57 |
| thisfred | urbanape: actually, two updates (if the folders already exist) | 16:58 |
| urbanape | right, but only one update if the move was internal to the folder (changing the order of bookmarks) | 16:58 |
| urbanape | at most, it will ever be two folder updates. | 16:59 |
| thisfred | pseudocode: folder1.contents.remove(docid); folder2.contents.insert_at(position, docid) | 16:59 |
| thisfred | yep | 16:59 |
| urbanape | yes, but we need to recognize that we're not just deleting docid from folder1 | 17:00 |
| urbanape | we're moving it. | 17:00 |
| urbanape | maybe | 17:00 |
| thisfred | well, the docid stays the same | 17:00 |
| urbanape | maybe it doesn't matter that we'd recreate it from scratch with the same docid. | 17:00 |
| thisfred | so we can deduce it, if need be | 17:00 |
| thisfred | if the docids are uuids | 17:00 |
| urbanape | the order of those events probably matters. | 17:00 |
| urbanape | oh, duh | 17:00 |
| urbanape | so the client needs to recognize a move | 17:01 |
| urbanape | and then it can make the local gesture. | 17:01 |
| thisfred | not really, because the document isn't modified | 17:01 |
| thisfred | (re order) | 17:01 |
| thisfred | so the worst could happen is: temporarily, it's in two folders, or in none | 17:01 |
| urbanape | yeah, but there's no semantic way in Firefox to have a bookmark be multi-present | 17:02 |
| urbanape | and there's already a move API. | 17:02 |
| rtgz | nautilus smb sharing tab is called "Share". In case file is shared using Ubuntu One it is not clear how to "unshare" the folder.. | 17:02 |
| urbanape | we need to have a way of saying: "If this rev represents the order of the children changing or if this and the next (or previous) represent a bookmark moving from one folder to another: make the move gesture locally" | 17:02 |
| rtgz | hey, how to unshare the folder from ubuntuone nautilus plugin ? | 17:03 |
| thisfred | urbanape: ah right | 17:03 |
| thisfred | so we need to translate _changes to firefox actions. | 17:03 |
| urbanape | thisfred: which would be easy, if we had that language in a revision annotation | 17:03 |
| urbanape | yeah | 17:03 |
| urbanape | which made me wonder about the field-level granularity in _changes | 17:03 |
| thisfred | simplest is to do the delete and add | 17:04 |
| thisfred | in that order | 17:04 |
| thisfred | and not worry about using move, unless this breaks firefox in some way | 17:04 |
| urbanape | the only thing it might break (and upset some power users) is that it might mess up internal accounting for last visited or number of visits, or something. | 17:05 |
| thisfred | urbanape: right. If it does, we should store that information in couchdb as well | 17:06 |
| thisfred | (or perhaps we should do so regardless) | 17:06 |
| urbanape | yeah, we've not been keep track of it today. | 17:06 |
| urbanape | to date, rather | 17:07 |
| urbanape | does batch updating happen in one revision? | 17:08 |
| urbanape | or one per item in the batch? | 17:08 |
| thisfred | urbanape: I think in a singe rev | 17:08 |
| urbanape | then that's the best way! | 17:09 |
| urbanape | batch PUT the two folders with their newly computed children | 17:09 |
| urbanape | and make the client recognize two folders changing in one revision as a move. | 17:09 |
| thisfred | urbanape: eh, I mean, a single db sequence number update | 17:10 |
| thisfred | but that's what you mean to I think | 17:10 |
| thisfred | too | 17:10 |
| urbanape | yeah, but isn't that what you get in the _changes feed? | 17:10 |
| thisfred | right | 17:10 |
| urbanape | sequence updates | 17:10 |
| urbanape | yeah | 17:10 |
| urbanape | sorry, yeah, in one sequence | 17:10 |
| thisfred | yep, should be able to make that work | 17:10 |
| urbanape | so, what do you think of my .application_annotations.field_changes idea/ | 17:11 |
| urbanape | ? | 17:11 |
| urbanape | so that clients can see which exact fields were updated and dispatch accordingly? | 17:11 |
| * aquarius catches up, sorta | 17:14 | |
| thisfred | I would hesitate adding this. It's hard to get right, and adds a lot of complexity that I'm not sure we absolutely need | 17:15 |
| urbanape | so, if location is no longer a part of the bookmark record, we could just walk the record on an update and impose everything we find. | 17:15 |
| thisfred | if the documents are more granular, as described above, it would not buy you much anymore for one thing: a change to a folder would always be a change to its contents field | 17:15 |
| urbanape | or its title | 17:16 |
| thisfred | right | 17:16 |
| aquarius | I have a few thoughts, which you may have already covered | 17:16 |
| urbanape | yeah, and we can test to see whether it's different | 17:16 |
| urbanape | "has the title changed? No, next." | 17:16 |
| aquarius | what happens if you move a bookmark from one folder to another? | 17:16 |
| aquarius | ( rtgz: sorry, I know you've asked a load of questions and I haven't responded) | 17:16 |
| urbanape | aquarius: two documents get updated: the old parent (its children field) and the new parent (its children field) | 17:16 |
| thisfred | pseudocode: folder1.contents.remove(docid); folder2.contents.insert_at(position, docid) | 17:16 |
| thisfred | aquarius: ^^ | 17:17 |
| urbanape | aquarius: we'd do it in one batch PUT | 17:17 |
| urbanape | and so would show up as a single sequence in _changes. | 17:17 |
| aquarius | and to reconstruct the structure you *have* to walk the folder tree starting from the root? | 17:17 |
| thisfred | aquarius: which can be done from a single view, I'm pretty sure | 17:17 |
| urbanape | yes, but each folder would always maintain its current set of children. | 17:17 |
| aquarius | thisfred, o rly? | 17:17 |
| thisfred | sure, | 17:18 |
| thisfred | just output ehh | 17:18 |
| thisfred | (order, id) | 17:19 |
| aquarius | how do you know which folder a document is in? | 17:19 |
| thisfred | for key folder | 17:19 |
| thisfred | id being the id of the child | 17:19 |
| urbanape | aquarius: given this approach, why would you need to? | 17:19 |
| thisfred | (id, order) is better for sorting | 17:19 |
| urbanape | everything internal to Firefox is addressable by our map of uuid to internal id | 17:20 |
| aquarius | urbanape, you update current-parent-folder and new-parent-folder. how do you know which document current-parent-folder is? | 17:20 |
| urbanape | ENOPARSE | 17:20 |
| urbanape | thisfred: I do think it would be easier to execute this maneuver with a bit of language, though. | 17:21 |
| aquarius | I move a bookmark from folder1 to folder2. You need to update folder1.children to remove bookmark, and update folder2.children to add bookmark, yes? How do you know the couch docid for folder1? | 17:21 |
| urbanape | it's the _id of folder1 | 17:21 |
| aquarius | ah, couchdoc._id == mozilla.internal_uuid ? | 17:22 |
| urbanape | yes | 17:22 |
| thisfred | I don't :), since you're introducing a whole new thing, storing "actions" which will need to be processed, removed, and replicated back and forth | 17:22 |
| aquarius | I missed that :) | 17:22 |
| urbanape | thisfred: consider moving a bookmark from front to back: old_f.children = [ a, b, c, d, e, f ] new_f.children = [ f, a, b, c, d, e ] | 17:23 |
| thisfred | urbanape: in the same folder? | 17:23 |
| urbanape | the index of every child changed, but to do that, all we need to do is make one statement: new_f.move(f, 0) | 17:23 |
| urbanape | yeah | 17:23 |
| thisfred | ok, so does firefox internally use indexes? | 17:24 |
| urbanape | it's hard to infer that programatically | 17:24 |
| urbanape | yes | 17:24 |
| aquarius | because you don't actually store the indexes explicitly on the document; they're just inherent in the order of the children mergeablelist | 17:24 |
| aquarius | except that mergeablelists have an _order | 17:24 |
| thisfred | well we can wrap that in a little bit of code surely | 17:24 |
| urbanape | aquarius: but Firefox uses an index when you tell it to move something or insert something somewhere | 17:24 |
| thisfred | aquarius: aha | 17:24 |
| thisfred | urbanape: yeah, we can just use the order in the list as the index | 17:25 |
| urbanape | what I'm saying is | 17:25 |
| aquarius | yeah, but your problem is that you don't get change notifications from firefox if a node's index changes as a result of some other change? | 17:25 |
| thisfred | we have to deduce the old order | 17:25 |
| aquarius | why not, when any bookmark changes, just re-serialise its whole containing folder? | 17:25 |
| thisfred | I would vote for that | 17:25 |
| urbanape | now we're back full circle | 17:25 |
| urbanape | that's what the manifest was for | 17:25 |
| urbanape | and did | 17:25 |
| urbanape | (and does) | 17:26 |
| thisfred | urbanape: but the folder documents do that too right? | 17:26 |
| thisfred | just more atomically | 17:26 |
| aquarius | 'cept having it all in one document is an invitation to conflict | 17:26 |
| urbanape | no, so the current state of things is that bookmarks know their location | 17:26 |
| aquarius | and having it in lots of separate documents makes conflicts less likely | 17:26 |
| urbanape | and the client exploits that knowledge when moving them in response to revisions | 17:26 |
| urbanape | ("aha, this bookmark's new parent and index is x and 0, so I'll make that gesture now. all tidy!") | 17:27 |
| urbanape | and we'd also update the manifest, which Bindwood would ignore, but something else (like the web UI) could make immediate sense of | 17:27 |
| rtgz | aquarius, no problem, I have a GNote with all my questions and feature requests :) | 17:27 |
| urbanape | "Ah, thank goodness, I don't have to walk the entire history from rev 0!" | 17:27 |
| thisfred | urbanape: I don't think we need to worry about the web ui | 17:27 |
| urbanape | I agree, now. | 17:27 |
| thisfred | ok | 17:28 |
| thisfred | so does that maybe eliminate the need for the manifest entirely? | 17:28 |
| urbanape | my point with my last "consider moving a bookmark" comment was: | 17:28 |
| aquarius | and bindwood doesn't need the manifest because it already knows what {the current, a recent} state of play is, because it's already got the bookmarks tree; the web ui hasn't? | 17:28 |
| urbanape | we need to be smart enough to recognize that in an 8-child folder, we don't need to make 8 moves to update each child's index, if we're just moving the last one to the first position | 17:28 |
| thisfred | if the above works, we could also just store parent ids on everything, and have the folders be near empty documents | 17:28 |
| thisfred | ah and the index | 17:29 |
| thisfred | and no | 17:29 |
| urbanape | aquarius: this new folder approach raises some new questions that I thorugh were dealt with when the bookmarks knew their position. | 17:29 |
| thisfred | folders with a contents field have my vote I think | 17:29 |
| aquarius | we do need to update them all, though, because either we're using MergeableLists (which have explicit indexes), or we're not (and then you fall prey to the problem that MergeableLists were designed to solve) | 17:29 |
| urbanape | aquarius: no, you don't | 17:29 |
| urbanape | so, consider: | 17:29 |
| urbanape | can we all get on the phone for a sec? my wrists are starting to hurt a bit. | 17:30 |
| * thisfred fires up skype | 17:30 | |
| urbanape | phone/skype/whatnot | 17:30 |
| aquarius | go for it | 17:30 |
| urbanape | thisfred: I'm urbanape on skype | 17:31 |
| thisfred | I'm gettring wires and pulseaudio soryed | 17:31 |
| thisfred | sorted | 17:31 |
| urbanape | woohoo | 17:31 |
| urbanape | I totally get that the .application_annotations.field_changes is untenable. | 17:50 |
| CardinalFang | Yeah. :\ | 17:57 |
| urbanape | the idea that it was per-revision had escaped the others, and aquarius reminded me that not all revisions might be replicated between hosts, so lots of semantics could be lost. | 17:57 |
| urbanape | in any case, we've just hashed out an even simpler solution. | 17:58 |
| CardinalFang | I'm interested in it | 17:58 |
| urbanape | cut out even more cruft. | 18:02 |
| urbanape | No need for a manifest at all now. | 18:02 |
| aquarius | urbanape, thisfred: modified tree traversal (or, how to store hierarchy in a DB of records): http://articles.sitepoint.com/article/hierarchical-data-database/2 | 18:02 |
| urbanape | folders will be present as records with two fields: title and children, children being an ordered list of child _ids. | 18:02 |
| urbanape | client will compute differences in children lists between two revs | 18:03 |
| thisfred | aquarius: urbanape yeah, I don't think there's anything better than for (order = 0; i < len(this.contents); order++) emit((this._id, order) , this.contents[order]) | 18:12 |
| dobey | hi again | 18:12 |
| dobey | yay speed | 18:12 |
| thisfred | dobey: stay away from that stuff dobey | 18:12 |
| dobey | *this* is high speed internet | 18:12 |
| thisfred | ah ok | 18:12 |
| dobey | hopped over to the office | 18:13 |
| dobey | now if i just had a working mouse | 18:14 |
| dobey | guess i should have swapped batteries before flight | 18:15 |
| dobey | any other branches i need to land before i start getting into coding? | 18:19 |
| dobey | yes there are | 18:23 |
| thisfred | urbanape: there is one alternative to the folders + bookmarks solution: storing the full path (as a list) and order in each bookmark. This way the folders are completely implied. | 20:26 |
| thisfred | but this will mean pain when moving folders around. nm | 20:27 |
| CardinalFang | Recompute them. Easy peasy. | 20:27 |
| CardinalFang | Well, not easy on races. I keep forgetting there's no atomicity. | 20:28 |
| CardinalFang | (Given my last employer, I shouldn't forget.) | 20:29 |
| * rtgz offline for openwrt reflash. goodbye cruel world! | 20:39 | |
| thisfred | CardinalFang: well, it's not superhard, but it's messier. Maybe that's the couch way though, and there's never the need to compute a tree or a subtree | 20:43 |
| thisfred | CardinalFang: you have bulk updates which are semi-atomic in a very quaint sort of way | 20:44 |
| urbanape | thisfred: yeah, thought of that. | 20:45 |
| thisfred | In this case a bulk update with all_or_nothing=True would probably work | 20:45 |
| urbanape | plus, you still need to keep the order (index) somewhere. | 20:45 |
| thisfred | urbanape: ah yes, for the folders | 20:45 |
| thisfred | really never mind then :) | 20:45 |
| urbanape | I'll stick with what we hashed out. | 20:45 |
| urbanape | I think it's very, very elegant. | 20:45 |
| urbanape | I only feel silly for not having figured it out myself over break. | 20:46 |
| thisfred | I have thought a lot less about the problem, which makes it easier ;) | 20:47 |
| urbanape | yeah, having all the background context made it hard to see it clearly | 20:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!