[10:43] morning people === thomas_ is now known as thomasvs [10:44] hey thomas [10:44] aquarius: so my last standing 'bug' is 100% CPU on the applet, just filed that with an strace log [10:45] thomas_, is it your quest to use every possible irc nick? ;-) [10:45] aquarius: sadly the applet doesn't seem to have a way to give me debug info to figure out what it's doing exactly [10:45] aquarius: heh :) [10:45] aquarius: I have three machines I regularly work from, my belgian desktop, my spanish desktop, and my laptop [10:45] aquarius: hence my interest in desktopcouch I guess :) [10:45] ah, hence many names, got it :) [10:45] * aquarius laughs! [10:45] yes indeed [10:46] 100% CPU, odd. Ah, just got the bug [10:46] ok, I'm going to wait for dobey to wake up for that applet bug before I dig into it myself [10:46] which means I"ll wait a bit more on doing the final test on this work desktop, but I just installed all packages and the applet popped up without throwing any error, and directed me to the u1 site, so stuff seems good [10:46] after that last bug is fixed I'll make some noise about the final packages [10:47] the applet is a dobey thing, so he will have a stronger clue than I do [10:47] ah, you already know this :O) [10:47] wow, so it's very close to being done. Thumpingly good work, that man :) [10:48] it's been a ride, but let's not claim victory just yet [10:48] I should find a machine to upgrade to f-12 too to check [10:48] what sort of noise? [10:50] aquarius: blogging about it, then submitting stuff to fedora's repo [10:50] I've had quite a few pingbacks on doing this, surprisingly [10:51] it's almost as if people are interested [10:51] it feels strangely motivating [10:51] oh, noise to alert people that you've done it, not noise at us about stuff beign wrong ;-) [10:52] I am well pleased that people are interested; I think it's cool tech [10:52] and already bringing it up on Fedora has shown areas where the code needs improving, which is immensely useful [10:52] or where we accidentally did Ubuntu-specific things without knowing it, like the certificate stuff [10:57] yeah, the hardest part is taking it from 'works on one thing' to 'works on two things'. from that point on it gets easier. [10:59] I'll remind you of that if ever a Windows port comes along :) [11:00] heh, well, that's an other thing entirely, but good to see that you at least consider it :) [11:03] certainly if the archangel Michael arrived and said "here is a diff to make desktopcouch work on Windows too" we wouldn't refuse the patch. I'd like to see DC on Windows/Mac too, definitely, it's just not going to happen in the very near future if I'm doing it. :) === JulioNeto is now known as julioneto [12:37] thisfred, you up for a conversation about design documents, or do you want to eat breakfast or something first? :) [12:44] aquarius: in a bit: foundations standup, then shower, so around 8:30 maybe? [12:45] *nod* (about 45 minutes?) [12:48] right [12:48] sry, for being US-centric, it rubs off quickly ;) [13:33] aquarius:: ready when you are [13:34] thisfred, this is actually something brought up by thomasvs. He's publishing CouchApps to his desktopcouch, and wants them on all his other desktopcouches [13:34] but...you can't write views to couchdb.o.u.c because you're not an admin [13:34] so views don't get synced [13:34] thus, fail [13:35] aquarius: ah, that would be a feature request in couchdb then? [13:36] we specifically exclude only viws with the u1_ prefix [13:36] weird though [13:36] rly? [13:37] users are allowed to create and delete dbs [13:37] so I should be able to write a design document to c.o.u.c? [13:37] so creating views should work too [13:37] aquarius: I think so [13:37] as long as it's in one of your dbs [13:37] obviously [13:37] thomasvs says that when replicating, it doesn't replicate design documents. thomasvs? [13:38] that would be a bug, either in our validators, or in couchdb itself [13:38] replication by default does take ddocs along right? [13:38] ah, good. I wasn't sure whether we were explicitly stomping on design docs :) [13:39] or do we need to flip something to allow that [13:39] don't you have to be an admin to write a design doc? [13:39] and users are not admins [13:39] aquarius: I don't have it all in my head, but I think we give users (damn near) admin rights in their own namespace [13:39] aquarius: or they wouldn't be able to create dbs either [13:40] I'm not sure exactly why this might not be working, which is why I wanted to make this problem part of your life :-) [13:40] aquarius: I'll have a quick look for any obvious stupidity in the validator function [13:40] me either, but we can find out [13:41] aquarius: we need to ask thomasvs to try direct replication over lan, to eliminate one source of the problem [13:41] (using d-c replication) [13:42] yes [13:42] aquarius: but if it's not that, I think it [13:42] s fair to drop it on my plate [13:42] I am starting to think that we need a proper replication test suite [13:43] function(newDoc, oldDoc, userCtx) [13:43] {if (newDoc._id.indexOf('_design/u1_') == 0) [13:43] {throw({forbidden : 'system design document'})}} [13:43] aquarius: +1 on that [13:44] the validator looks fine [13:47] yeah, so that can't be the problem. weird. let's see what thomasvs has to say when he's free [13:56] aquarius, seen mandel? [13:56] not today, nope [13:56] apparently he has an actual job he has to attend to sometimes :) [13:57] he does? :-) [13:57] just did some more tortur^W reviewing of his branch :-) [14:00] Chipaca: hola. you rang? [14:01] hmm [14:13] aquarius, thisfred: ok, I will doublecheck that it actually doesn't work, maybe I did something wrong. It makes it harder seeing as I can't actually see what's in my u1 couchdb :) [14:13] aquarius, thisfred: I will try the sync on my work desktop as soon as dobey has a solution for the 100% cpu applet thing :) [14:15] thomasvs: yeah, I understand. aquarius is there a reason why we shouldn't publish something like webm0nk3y's web_api tool for debugging purposes? [15:01] it's time! [15:01] Desktop+ MEETING BEGINS [15:02] aquarius Chipaca__ dobey urbanape CardinalFang teknico jblount [15:02] me [15:02] you know how it works [15:02] me [15:02] rodrigo_: [15:02] me [15:02] me [15:03] me [15:03] 𝗺𝗲 === Chipaca__ is now known as Chipaca [15:03] me [15:03] me [15:04] DONE: landed the branch updating the Funambol code to v. 8.0 (#403435), reviewed mandel's branch again [15:04] TODO: expose SMS methods in Funambol Server API (#381398), triage my 20 bugs [15:04] BLOCK: none [15:04] next: vds [15:04] DONE: funally finished the two branches to port funambol v8 in sourcedeps, tried to start funambol on a random port to make funambol one of the server that starts with make start but no luck, I guess we'll start it only if we need it, triaged bugs, discussed about the status of the mobile sync, started a branch to wrap funambol sms api [15:04] TODO: finish the branch [15:04] BLOCKED: nope [15:04] CardinalFang: please [15:05] DONE: reviewed mandel's branch. Made draft desktopcouch API for attachments. [15:05] TODO: throw it away and start over. [15:05] BLOCKED: None [15:05] jblount, what's for lunch, and your goals? [15:06] DONE: Bugs sorted, meetings, post-holiday fuzz worked through [15:06] TODO: I have some bugs to deal with on the /files/ ui, ping johnlea about some contacts stuff [15:06] BLOCKED: Nope [15:06] rodrigo_: ! [15:06] • DONE: Added couchdb-glib documentation to xdg page. Looked at music store API. Fixed a bug in Evolution contact preview widget. Music store architecture discussions and planning. Contacts picker [15:06] • 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? Talk to John Lea about contacts widget mockup [15:06] • BLOCKED: no [15:06] Chipaca: go! [15:06] DONE: lots of emails and meetings. TODO: continue talking about music store, and nail down somebody or somebodies to fix NoAccessToken bugs. BLOCKED: nevah! NEXT: dobey [15:06] ☺ DONE: Triage, Backporting, Arguing (it builds character, and teams) [15:06] ☹ TODO: More backporting, Triage, Prepare releases/SRUs [15:06] ☹ BLCK: None. [15:06] aquarius: hit it [15:07] ⚀ DONE: music store planning [15:07] ⚁ 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 [15:07] ⚂ BLOCKED: [15:07] chipaca, go [15:07] er, oops [15:07] not Chipaca :) [15:07] urbanape, ? [15:09] aquarius: you were the last 'me' [15:09] I was indeed [15:10] so EOM I guess, thanks! [15:22] dobey: let me know if you have time to look at that applet bug [15:23] thomastp: it's one of the hundreds of bugs i have to look at i guess, yes :) [15:23] dobey: uh oh :) [15:23] dobey: well, maybe a first feedback would help [15:23] for example, should the applet have logging ? [15:24] it does, but i don't think it would help here [15:25] aquarius, Attachments! [15:25] CardinalFang, I can't send email, smtp.canonical.com keeps timing out :( [15:25] thomastp: the stable release only logs INFO and ERROR, and the only way to change it is edit the code to log DEBUG and worse [15:26] aquarius, scenarios: You are making a new record. [15:26] thomastp: if you change ubuntuone/oauthdesktop/logger.py to have logging.DEBUG for LOG_LEVEL instead of logging.INFO, you'll get more log messages, but probably nothing particularly relevant to your bug [15:26] dobey: so, you'd accept a patch for example to add an option for that ? [15:27] aquarius, r = Record(...); r.attach(f, "name"); db_obj.put_record(r) ? [15:28] CardinalFang, ya [15:28] thomastp: the applet will be going away soon. [15:28] aquarius, Next scenario: you already have a record. [15:29] dobey: oh ? [15:30] thomastp: yes, we're going to be fixing the experience to not involve opening a browser, and to be more well integrated into the file manager/etc... and the applet won't exist. [15:30] dobey: ok, so not much point focusing on improving it, and also unlikely you'll look at my bug :) [15:30] aquarius, r = dbobj.get_record(record_id); r.attach(f, "name"); ... # then what? dbobj.update_fields(record_id, d) does not work. [15:30] thomastp: i have a feeling that the 100% cpu thing may very well be something with twisted [15:31] "does not work" == "is ugly". [15:31] CardinalFang, er, dbobj.put_record(r), no? [15:31] dobey: me too [15:31] CardinalFang, same as if I change a value [15:31] thomastp: well i haven't seen any complaints to that effect about the applet on ubuntu. but i will definitely put a fix for it in stable-1-0 [15:32] aquarius, ah, I guess so. Hrm. [15:32] thomastp: there are some other complaints too, that pulling twisted out of the applet would fix [15:32] dobey, quit yer hatin' on Twisted. [15:32] CardinalFang, so, fetch-record, add-attachment-to-record, put-record. [15:32] thomastp: does syncdaemon also use up 100% cpu in the same manner? [15:32] dobey: nope [15:33] dobey: I've had twisted+gtkreactor taking 100% cpu bugs before due to a bug in python, I thought I had a fix for that installed, but not sure [15:33] CardinalFang: if it would only stop screwing with the main loop timing... [15:34] dobey: screwing how ? [15:35] thomastp: the glib/gtk reactor alters some timing in the glib main loop [15:35] thomastp: so it wakes up once every 10 seconds at least [15:35] even if it doesn't really need to [15:35] every tenth of a sec you mean ? [15:35] that's pygtk I think [15:36] maybe 10 times/second yeah [15:36] let me see [15:37] that would be this bug: https://bugzilla.gnome.org/show_bug.cgi?id=481569 [15:37] Gnome bug 481569 in gobject "Calling gobject.threads_init() causes a lot of wakeups" [Normal,Resolved: fixed] [15:37] bug 475447 [15:37] Launchpad bug 475447 in ubuntuone-client "Ubuntu-One client/syncd cause 10 wake ups / second each" [Undecided,Incomplete] https://launchpad.net/bugs/475447 [15:38] aquarius: sorry, out today watching the sick kid [15:38] urbanape, no problem, I wasn't sure [15:40] thomastp: hrmm, interesting [15:40] thomastp: but twisted also does stuff [15:41] What's the best way to store a date field in CouchDB? seconds-since-epoch, ISO 8601 or application-specific (bad-bad-bad). Empathy uses %Y%m%dT%H:%M:%S which is neither of the above and it looks ugly. [15:42] dobey: what sort of stuff does twisted do that causes issues ? [15:42] my experience with twisted has been nothing but stellar [15:46] thomastp: the gtk2/glib reactor does some stuff with iteration timing [15:47] thomastp: see the doIteration and simulate methods in Gtk2Reactor [16:04] rtgz, ISO 8601. [16:05] rtgz, Empathy's is 8601 except for time zone? [16:05] CardinalFang, it is missing the dashes between y,m and d + missing timezone [16:05] CardinalFang, message time='20091029T18:25:15' [16:06] CardinalFang, erm, it is defined by standard as well... [16:06] Ah. Dang. So close. [16:07] rtgz, ah. right. """So a time might appear as either "134730" in the basic format or "13:47:30" in the extended format.""" [16:07] * CardinalFang hugs Wikipedia. [16:07] CardinalFang, The extended formats are preferred over the basic formats not only for human readability, but because some basic formats can appear to be ambiguous to those unfamiliar with the standard. [16:07] * rtgz is happy [16:10] rtgz, Python datetime.datetime needs a striso8601ptime function. [16:12] * CardinalFang wishes he could talk to aquarius. [16:13] thisfred, you alive? [16:13] CardinalFang: yessir [16:14] thisfred, great. desktopcouch and attachments. On Record, .attach(file, str), .detach(str). How should we retrieve an attached blob? [16:14] I'm trying to think of what's Pythony. [16:15] CardinalFang, isoformat() looks fine to me... and fromtimestamp()... [16:15] from the db? record.get_attachment(attachment_id) and have that return a file like object? [16:16] thisfred, record doesn't know anything about the db. It holds data. [16:17] db.get_attachment(record, attachment_name) ? [16:17] CardinalFang: it could defer to a database method get_attachment(record_id, attachment_id) [16:17] exactly :) [16:18] or does it not hold a reference to the db at all? [16:18] None at all. [16:19] If so, it probably should. I'd like to be able to record.store(id=None) and record.load(id) [16:19] or something [16:19] unless there's a good reason not to have the reference [16:19] I forget [16:19] but I don't think so [16:20] As it is, thisfred, one could get a record from one place and put it in another place. We'd lose that. [16:20] Ideally, a developer would not have to instantiate a database object in most cases [16:20] * CardinalFang thinks. [16:20] CardinalFang: we could make a copy of the object and change the underlying db [16:21] perhaps [16:21] oh noes, who broke the aquarius? [16:22] CardinalFang: record as is is independent of couchdb, which is kinda nice [16:22] but probably not all that useful [16:25] thisfred, How about this: When I build a record, fabricate getter functions for those attachments, with the source DB object in the closure. [16:28] CardinalFang: that could work, but it's more complicated than storing a reference to the db, and has no obvious (to me) advantages. I'd store the reference when we get a record from the db, and make the get_attachment method fail if self._db is None or some such [16:28] <__lucio__> aquarius_broken, ping [16:28] then we could also have self.save(id=None) [16:29] that would call to the db.store_record() or whatever it's called [16:29] "put_record" [16:29] we are creating a two way dependency between Database and Record, but I think that's ok, since they're in the same package === Chipaca_ is now known as Chipaca [16:30] CardinalFang: either way, I'd like to hear aquarius_broken [16:30] on the subject [16:51] hey [16:51] sorry, stupid web client [16:51] what would you like my opnion on? [16:52] __lucio__: pong [16:53] aquarius_broken, thisfred suggests binding Record to CouchDatabase. One can operate on Record directly and update a source database. [16:53] I don't think so. I quite like that Records are independent, and you have to explicitly db.put_record to store them [16:55] aquarius_broken: ok, but that means you'll have to do db.get_attachment(record_id, attachment_id) as well [16:55] not a big problem IMO, but not as pretty as record.get_attachment(attachment_id) [16:55] why? [16:55] aquarius_broken, I like that they're separate too, except I'm trying to decide on the best way to get attachments. I attach() and detach() are on Record. When we get a record, we don't want to download every attached BLOB so that we do not need the DB any more. [16:55] I think that record.get_attachment should fetch the attachment when it's asked for [16:56] agreed, so there's a binding there [16:56] there is a Russian joke about Chukchi. It states: There was a writers contest in some newspaper and one of the participants was Chukchi. When the editorial staff got to the text they could not understand anything. So they called that Chukchi and asked. "Have you even read the thing you mailed us?". And the response was "No, chukcha is writer, chuckchi is not reader". [16:56] aquarius_broken: for that it needs a reference to the db [16:56] but basically a Record stores a reference to its attachments [16:56] and then lazily fetches them on demand [16:56] I admit that this slightly breaks the "be independent" thing [16:56] * rtgz finished the prototype for Telepathy messages stored in CouchDB, Text only. Now he needs to find out how to read things back in a user-friendly fashion [16:56] <__lucio__> aquarius_broken, do you have enough internet so we can discuss file sharing as a content delivery platform? [16:56] aquarius_broken, thisfred, give me a while and I'll show you an idea implementation. [16:56] but we're only stepping away from that for performance reasons; think of this as a performance optimisation [16:57] __lucio__: I do, I think, as long as it's here [16:57] __lucio__: I can only get web access, and freenode has the web client [16:57] CardinalFang: ok [16:57] I hate my life, incidentally, in case it wasn't clear [16:57] aquarius_broken, who's your Intertubes provider? [16:58] ...normally? [16:58] <__lucio__> aquarius_broken, ok. so, i think that doing that with file sharing is interesting. but id like to have a bigger idea before we so one implementation. statik gave me a list of possible uses of content distribution [16:58] CardinalFang: Virgin Media [16:58] __lucio__: yep [16:58] <__lucio__> aquarius_broken, would we make all of this work around UDFs? whats the best user experience we can think of? [16:59] best user experience I can think of is music into ~Ubuntu One/Purchased Music or ~/Music/Purchased, and make rythymbox automatically notice music there [17:00] __lucio__: the best user experience *I* can think of is that clicking a song downloads it in the background; when it's downloaded it appears in your music library in yoru music player; songs are actually stored in a folder inside your current music library folder called "Ubuntu One Purchased Music", and that folder is a UDF [17:00] ~/Ubuntu One/Purchase Music is perhaps better because it makes it clear that the music is consuming storage quota, and that the user can copy music out [17:00] to stop it being synced === Chipaca` is now known as Chipaca [17:01] <__lucio__> aquarius_broken, what kind of notifications would the user get? general "file download" notification? or something better? like "you have finished downloading the album XYZ"? [17:01] statik: that's what emblems are for, though. If we think that people will be confused or not understand which folders are synced, then we need to solve that problem [17:01] statik: in order for UDFs to be acceptable [17:01] sure [17:01] <__lucio__> statik, i dont like magic folders inside ~/ubuntuone [17:02] :-/ [17:02] CardinalFang just started talking about bittorrent [17:02] __lucio__: the way I'm imagining it working is that when you buy a song, you'll be shown, inside the music player, which songs you've recently purchased and whether they're downloaded or not (so there'll be an "in progress downloading" page, much the same as Software Centre has an "In Progress" page, so we're consistent with them) [17:02] __lucio__: question: can we create a share owned and shared to the same person? [17:03] also i promised popey that we would give him free music [17:03] :D [17:03] <__lucio__> aquarius_broken, so, how would the music store know which files are actually the ones that are being downloaded? [17:04] I like re-using syncdaemon code to download music. I hate that it has anything to do with my ~/Ubuntu\ One directory. [17:04] <__lucio__> aquarius_broken, do we do one UDF per song, per album, per purchase, for all the purchased music? [17:04] statik: fabsh wants music too: http://twitter.com/fabsh/status/6229442644 [17:04] because it knows which ones you chose, so it can look in the folder and see if they're there yet. [17:04] <__lucio__> Chipaca, you dirty thing [17:04] __lucio__: I think your Purchased Music folder is a UDF [17:05] your honor, he's not answering my question [17:05] <__lucio__> Chipaca, yes we can. it may have some side effects we have to hunt and kill. [17:06] __lucio__: correct me if I'm wrong, but wouldn't that be a quick-and-dirty non-documented way of getting a UDF? [17:06] <__lucio__> Chipaca, that means that it will use double the disk space [17:06] <__lucio__> Chipaca, and the location would be ~/Ubuntu One/Shared With Me/My Purchased Music [17:06] hmmm [17:07] * rodrigo_ needs to get out for a little bit, will follow the discussion from the log [17:07] yeah, must go get food and do some errands [17:08] Lunch. Back to yell about music in 1h. [17:10] <__lucio__> aquarius_broken, we need soemthing better. when you install apps you have units that are bigger than single files, whole apps. so if i buy a disk, i dont want to follow every single file to know if it finished downloading. [17:11] __lucio__: yeah, but songs aren't like that. [17:11] you buy a song, it's a song. [17:13] CardinalFang: should bug 442120 be fix released for the desktopcouch project (i assume it should be since it's fix released on the package/karmic) [17:13] Launchpad bug 442120 in desktopcouch "desktopcouch-service crashed with RuntimeError in find_port__linux()" [High,Fix released] https://launchpad.net/bugs/442120 [17:14] <__lucio__> aquarius_broken, albums are. [17:14] so? look at, for prior art, the existing Amazon MP3 downloader; it shows you download progress per song, even if you buy an album. [17:15] If what you want is download progress for the whole album at once, that's not hard to do. [17:17] <__lucio__> aquarius_broken, we could just change what we show client side. the downloads in progress already is code we have to do, right? [17:17] <__lucio__> so we can have specific messages and everything appropriate for content delivery [17:18] __lucio__: yeah, but it's almost entirely trivial code. (for file in things_downloading: if os.path.exists(file): print "done"; else: print "waiting") [17:18] and it can certainly be done with more detail than that if you want [17:18] I'm just thinking about the minimum requirements here [17:19] * rtgz posted http://blog.rtg.in.ua/2009/12/telepathy-logging-to-couchdb.html [17:19] <__lucio__> aquarius_broken, you can use dbus and give better information [17:19] <__lucio__> aquarius_broken, but yes, we can give whatever user experience we want as long as the music store app knows what files make each item/purchase [17:20] __lucio__: absolutely, and that'd be really good :) [17:20] __lucio__: and it will know [17:22] <__lucio__> aquarius_broken, so, if we put stuff in ~/Ubuntu One/The music i paid for/ , what happens when we have UDFs? How do we get that into rhythmbox? [17:22] <__lucio__> aquarius_broken, what if a user with a netbook wants to buy gigabytes of music? [17:23] __lucio__: ah, that's still to be decided. What *I* think is that we create a "Purchased Music" folder which is a subfolder of your music library folder (~/Music by default) and we make Purchased Music a UDF. [17:23] users with a netbook: what about them? That's no different to the case of "what if a user with a netbook wants to store 50GB of OpenOffice documents in U1", is it? [17:23] <__lucio__> aquarius_broken, theres is real risk that we cant do UDFs for lucid. [17:24] __lucio__: yep, so if UDFs don't arrive then the folder is ~/Ubuntu One/My Purchased Music, and we add a symlink to that folder to the music library. A better solution would be to teach media players about multiple library folders, but I think that will be hard. [17:24] <__lucio__> aquarius_broken, how about migration then? [17:24] migration? [17:25] rtgz: sweet empathy work! I have a couple of questions about it once we've finished this discussion, if you have time later? [17:27] __lucio__: do you mean: if we set up that symlink for Lucid users, and then we get UDFs in lucid+1, should we make the folder a UDF automatically? [17:28] __lucio__: if so, I think no. Since at the moment we don't detect if someone's changed ~/Documents to be a symlink to ~/Ubuntu One/documents so they get their docs synced, we shouldn't try and be cleverer than that for music. [17:30] <__lucio__> aquarius_broken, ok. what about the "content delivery api", is that a public api? internal api? is the serive just "give X to Y"? do we do it just because we dont want to touch the music store pprivate api? what exactly the benefit it gives to each party? [17:31] there isn't a "content delivery API". We have the ability, on the one.ubuntu.com server, to add new files to a user's Ubuntu One folder if they ask for them somehow (by purchasing some music from our music store, for example) [17:32] the benefits it gives for users are: they already understand Ubuntu One and how its files work; this is an extension of that. It means that things that they get from Ubuntu One are automatically Ubuntu One data, which means they'll act like other data they've put in Ubuntu One. It provides a consistent home and experience for all dealings with Ubuntu One services. [17:33] Benefits it provides for us, the U1 team: we've already spent ages building a way of getting files from o.u.c to desktops, which is robust and clever and can cope with your net connection being flaky or limited bandwidth, so we're using it again rather than building a new thing which will *also* have to cope with those things [17:35] aquarius_broken, sure [17:38] <__lucio__> aquarius_broken, there is an api, i wont let you get your hands on the model code and just touch the db :) [17:39] __lucio__: ah, right, yeah, but that API will be called by code in the server from the web, it's not exposed as an actual API to the outside world. :) [17:39] __lucio__: I wasn;t planning on just writing sql, promise ;) [17:40] <__lucio__> aquarius_broken, maybe its just the controller, and you have to take care yourself about getting stuff into s3 [17:41] __lucio__: yeah. I haven't thought massively about the exact detail of how that'll work yet [17:43] <__lucio__> aquarius_broken, re: we still have to build something to get files from the store provider. so whoever does that can put them on s3 i imagine. [17:43] __lucio__: yeah, that, to be honest, sounds reasonable, although reusing the existing put-files-on-s3 code as much as possible would be good [17:46] <__lucio__> aquarius_broken, it can be as easy as some_s3_lib.put(storage_key, content) m but it gets a bit more complex when you want streaming, resumes, etc [17:46] __lucio__: yeah. I don't know anything about the existing code that does this stuff, but obviously I am going to need to :-) [17:47] <__lucio__> aquarius_broken, welcome to twisted [17:47] yay [17:50] but my love for twisted aside, does the plan make a bit more sense now? SOrry if I didn't explain this in enough detail before :) [17:52] __lucio__: and does that cover your worry that syncdaemon wasn't right for the job? [17:54] <__lucio__> aquarius_broken, yes, i like it now. i worry that the user experience may get a bit complex or we fail to provide good information to the user. but thats back to your field [17:56] __lucio__: I spend all day and night thinking about that, don't worry :) [17:56] __lucio__: so if it turns out rubbish after all, you can blame me, and then you can shoot me. [17:56] <__lucio__> aquarius_broken, i only care about the shooring [17:56] <__lucio__> shooting [17:57] __lucio__: haha! bring it on. I saw you with the handgun at UDS :) [17:58] <__lucio__> :) [17:59] right, good, I'm glad your worries have been alleviated :) [17:59] <__lucio__> aquarius_broken_, but seriously, please think hard on how you are going to make sure we can provide enough information and still give a good ux. for example: having syncdaemon say "finished syncing" and the music store say "songs downloaded" at the same time may not be the best thing [18:00] absolutely agreed [18:03] I'm still mulling over how to indicate song download completion [18:03] __lucio__: you mean via notifications? [18:03] need to prototype a couple of things, perhaps :) [18:03] because syncdaemon notifications for success are going away [18:04] indeed they are [18:04] and I'm not sure I want to replace them with music-store notifications for success :) [18:04] <__lucio__> Chipaca, whatever we show the user [18:05] instead, I think the download progress page should do it [18:05] but I need to prototype that just so people know what I'm talking about :) [18:05] <__lucio__> Chipaca, no more: "you have X new files"? [18:05] __lucio__: yes, no more "downloaded 2156 of 1346563456678865" [18:07] <__lucio__> Chipaca, what about "you have X new files"? its not the same [18:08] __lucio__: nope, sorry [18:09] <__lucio__> Chipaca, why? [18:10] __lucio__: design says they suck (and I tend to agree) [18:10] <__lucio__> Chipaca, design said we had to have them [18:10] hmmm [18:11] * aquarius_broken_ shows his trying-to-look-surprised face :) [18:11] __lucio__: when was that? [18:11] <__lucio__> Chipaca, before karmic [18:12] __lucio__: give me a second [18:12] __lucio__: do you really want to read the spec? [18:13] <__lucio__> Chipaca, will it give me more info apart from "notifications are sooooo last year"? [18:14] * Chipaca reads [18:14] __lucio__: no [18:15] <__lucio__> Chipaca, oh, well. your problem :) [18:15] __lucio__: yes [18:15] john__: ping [18:17] Chipaca, Hi [18:17] john__: are _all_ u1 notifications going out? [18:18] john__: I mean, in the spec as "we won't do this anymore" [18:19] john__: if so, we'd like to know why; last year we had to put them in, so it would good if we could know the rationale [18:19] I would also like to know the rationale as to why they were added last year ;-) [18:20] john__: otherwise it would just sit there doing nothing [18:21] the notifications were actually welcomed, in general, even if they aren't 100% accurate some of the time [18:21] one sec... [18:22] Ubuntu One should not issue notifications in direct response the user's own actions. If a user has just saved a file, they don't need to be told that the file is synced. If the file fails to sync the user should be alerted to the error however this is a separate discussion. [18:22] Ideally notifications should be issued when another user updates a file that the current user has access to (both when they have shared the file and when the file is shared with them). This is a means by which the user can receive situational awareness of other users interactions with data that falls within his or her scope. This is functionality is one element of a possible events framework that is not currently in scope [18:22] basically we should not issue notification in direct response to a users own actions [18:23] john__: and if a user needs to know if a file is sync'ed before, say, unplugging and going home? [18:24] john__: we do notify them when they turned the music up, how is this different? [18:25] The user should be able to check that the sync is complete if they need to, but we shouldn't push notifications continuously in response to user actions. Knowing if the computer is currently: In sync, syncing or disconnected can be perhaps handled differently. [18:25] Chipaca: isn't this what the emblems are for? [18:26] Chipaca: files/folders that are partially synced have the partial emblem [18:26] aquarius_broken_, Chipaca the users are not going to dive into their directories to find out whether a particular file is synced or not [18:27] rtgz: but the notifications don't help with that either [18:29] aquarius_broken_, if the bubble said "the files are synced" then I believe it. If I put a file into the directory and nothing tells me it is synced then it is not synced probably. And if I put the whole directory structure then I don't see infdividual emblems. It's not like remote nfs/sftp/smb connection when files are 'there' when they appear 'there'... [18:30] bbiab, dogwalk [18:30] Chipaca, good question. I think the answer is historical and that it is the expected behaviour from TVs etc.. There is also the difference between a single purpose wigit where the user is adjusting a single parameter and reporting more complex interactions which do not solely involve the changing of a parameter. I think this needs to be articulated more clearly. [18:30] rtgz: yeah, but a folder which is partially synced should have the partial emblem on [18:30] something like 'current tasks' like in the Software Store... [18:31] * Ubuntu Software Center [18:32] aquarius_broken_: agree [18:32] rtgz: wanna talk about the empathy thing? (great work on that, btw!) [18:32] aquarius_broken_, erm, am I too boring regarding the notifications? :) [18:33] rtgz: not at all, if you're staying involved in that discussion then I can wait :) [18:34] hrmm [18:34] aquarius_broken_, okay, so, re: empathy, telepathy and im logging. Currently only single user chats are implemented, it requires PPA version of mission-control. [18:35] rtgz: you're storing details of chats, yes? [18:35] arguing about notifications? [18:35] rtgz: so it's not actually specific to empathy? pidgin could use it too, for example? [18:36] aquarius_broken_, the main questions as I see it at the moment is how to DISABLE logging for particular conversation since Telepathy does not provide anything of such kind. Empathy guys added a gconf entry globally enabling/disabling the logging but it is weird for an external logger to peek into gconf for Empathy to find out the setting [18:37] aquarius_broken_, it is Telepathy-specific client listening to DBus messages and reacting when telepathy sends notifications about new channels (new chats) [18:37] rtgz: ah, sorry, I wasn't clear. YOur client is Empathy-specific, certainly. But if Pidgin decided to store its logs in desktopcouch, it could use the same record format, yes? [18:38] john__: if you want to know why they were added, ask beuno/djsiegel [18:38] hey, do you know if it's possible to have a U1 app you can feed with a string i.e. "chromium-browse,xmoto" and get that installed across all your computers? [18:39] aquarius_broken_, the actual format for this record type is simply { "_id": "e9db6404d7970a7869c00381f3c845b3", "_rev": "1-631d84ba5af857958138fef0666d66da", "from": "en2pl@bot.talk.google.com", "to": "roman.yepishev@gmail.com", "record_type": "http://www.rtg.in.ua/empathy-im-couchdb", "time": "2009-12-01T20:15:46", "protocol": "jabber", "message": "Bot Szanowni Państwo, let's chat!"} [18:39] artir: no. but you could write a simple shell script to do it with ssh and apt-get [18:40] dobey: and if my computer is out of my local network? [18:40] and i don't want to have it on :) [18:40] i waws thinking of storing the string in a desktopcouch, which gets replicated and then parse the string with python and install that (the program would need to run as root) [18:40] aquarius_broken_, script snapshot: http://paste.ubuntu.com/332530/ [18:41] rtgz: yep, that's what I thought, so that'd work fine if pidgin wanted to store their logs too. So...could I suggest that you change the record type to be something more neutral? One of the things I want to do is to encourage different apps to collaborate by using the same record type for things [18:41] rtgz: it'd be great if pidgin stored logs and then when I switched to empathy all the logs were still readable by empathy [18:41] aquarius_broken_, sure, the main part was to find out how to get the data from telepathy, not how to put it into the CouchDB :) === artir is now known as RainCT_ [18:42] rtgz: yes indeed -- the bit I'm most impressed with is that you got the data from telepathy, but the bit I'm most concerned about being right is how it goes into desktopcouch ;-0 === RainCT_ is now known as artir [18:43] john__: https://wiki.ubuntu.com/UbuntuOne/KarmicClient [18:43] rtgz: also, it's a really good idea if the record_type URL actually points to a page which describes the record_type (some notes ni human-readable format are fine; it doesn't have to be a schema or anything) [18:44] rtgz: although I note that you have a page there which says "see the blog", which is good :) [18:44] rtgz: record types don't have to be defined at freedesktop -- they can be any URL [18:44] rtgz: there's no "official register" or anything :) [18:45] aquarius_broken_, Basically we need from, to, date and them message itself. However this list has to be extended for protocol, or account, etc. since there may be 31313 icq display name and... no idea who else wants to have such id in another network, but they are able. [18:46] rtgz: yeah; you'll almost certainly want some indication of which protocol it was, I think? [18:46] aquarius_broken_, They should be at freedesktop, cause telepathy is part of freedesktop, desktopcouch is part of freedesktop and I don't like that google site :) [18:47] * aquarius_broken_ laughs [18:47] aquarius_broken_, I suspect that the logs are of no use if nothing can read them so it is necessary to create a log reader that reads directly from couchdb and see what bits are missing [18:47] rtgz: it would be good to bring up the format on the desktopcouch mailing list for discussion, perhaps, and mention it to a pidgin developer or amsn developer to get their thoughts into the discussion? [18:49] aquarius_broken_, the guys at #telepathy had an idea to finally create external logger/framework some week or two ago (the only existing external logger so far is in Nokia's Maemo) [18:50] cool! [18:50] your work would be an excellent demonstration of that :) [18:50] aquarius_broken_, ... and the fact that it will not work in karmic default install [18:51] ? [18:51] won't it? [18:51] oh, you mean because the telepathy logger stuff won't be there, right [18:51] I thought you meant that desktopcouch was broken :) [18:52] aquarius_broken_, the mission-control shipped with carmic has a bug preventing new channel notification if you were the one who originated the chat :( [18:52] :( [18:52] * rtgz either writes karmic or karmik, not carmic o_O... [18:53]