[00:35] <urbanape> jblount, I figured it out. I was never unsubscribing that button from the action, so every time you click it, it adds on more subscribers.
[04:24] <statik> all better now
[13:46] <urbanape>  jblount: fixed the extra event subscribers. Pushing now
[13:47] <urbanape> question: If a file is public, should its URL that we expose in the file table be its public URL?
[14:06] <jblount> urbanape: Is there a good reason for that? Swapping the urls out seems like extra complication for little benefit.
[14:07] <urbanape> no, no particular reason, just asking
[14:07] <urbanape> consistency, really.
[14:07] <urbanape> then, you could just right-click on the URL, copy it, paste it into IM or whatever
[14:07] <urbanape> if the file is public, always deal with its public URL.
[14:07] <jblount> Yeah. I'd actually prefer it becuase it exposes the url closer to top level...
[14:09]  * jblount takes note that public files probably need to be indicated as such somewhere in the ui other than just in the details overlay
[14:09] <urbanape> also a good idea
[14:09] <urbanape> I had these questions for johnlea yesterday, but he was away
[14:09] <urbanape> if he wants to chime in ^^
[14:13] <johnlea> urbanape: what's the question?
[14:13] <urbanape> should we decorate the file table entries in any way when they're available as a public file?
[14:17] <johnlea> urbanape: the file table is not exposed through the UI?
[14:17] <urbanape> ?
[14:17] <johnlea> urbanape: what is the file table?
[14:17] <urbanape> in the /files/ ui
[14:18] <urbanape> in the web UI, if a file is public, should we decorate it any way so that the user can see at a glance?
[14:18] <johnlea> ahhh, you are talking about the files page on the website
[14:18] <johnlea> yes
[14:19] <johnlea> we need to design how published files are going to be indicated on the desktop, and then when that is agreed use that as the basis for modifying the website
[14:20] <urbanape> so, nothing right now. that's fine
[14:21] <johnlea> my todo list is: 1. file sync (UDFs) 2. file share 3. file publish
[14:22] <Overtone_> My machines are not sync'ing at the moment. Is this a common problem for anyone?
[14:23] <urbanape> johnlea, does that mean we shouldn't have the publish capabilities exposed in the web ui yet?
[14:25] <jblount> urbanape: No. We're not going to wait to expose this feature until it's ready on the desktop.
[14:25] <jblount> Overtone_: You are the second person I've heard report it, and I know we're having some database related issues.
[14:26] <Overtone_> Is there anything I can do to help debug it?
[14:28] <jblount> Overtone_: I don't believe so, all of our db hackers are working on it right now.
[14:28] <Overtone_> OK, I'll wait a while and try again later!
[14:33] <jblount> Overtone_: Thanks, sorry for the trouble!
[14:37] <dobey> hrmm
[14:40] <johnlea> urbanape, yes hold off exposing the publish capabilities in the web interface until we have designed how it will work on the desktop
[14:40] <urbanape> johnlea, jblount, and anyone else involved: Please work out a consistent story.
[14:43] <dobey> heh
[14:43] <dobey> this one time...
[14:43] <jblount> urbanape: Keep hacking, I'm pretty sure statik wouldn't want us to slow down on this and doesn't want to wait to expose the feature, but he's a little busy with the db weirdness.
[14:44] <urbanape> this calls for Thunderdome.
[14:44]  * dobey goes over to the xbox and puts in Borderlands
[15:00] <johnlea> urbanape, jblount: I'm not sure it is worth implementing a feature that without a design when it is due to be designed in the near future.  You can implement something, but it after the design work is done the required functionality is different the work may be wasted.
[15:00] <johnlea> if
[15:01]  * johnlea going into meeting
[15:01] <dobey> johnlea: do you and otto have a few minutes for a call today?
[15:09] <jblount> Desktop+ MEETING BEGINS (although a little late)
[15:09] <jblount> Say "me" to document your status, we're doing DONE / TODO / BLOCKED today.
[15:09] <CardinalFang> me
[15:09] <jblount> me
[15:09] <teknico> me
[15:09] <aquarius> me
[15:10] <jblount> me
[15:11] <rodrigo__> me
[15:11] <dobey> me
[15:12] <CardinalFang> Ready?
[15:13] <jblount> CardinalFang: I'm ready !
[15:13] <CardinalFang> DONE: Found bug/test-failure in merged Tomboy/Notes code.  Half sick-day
[15:13] <CardinalFang> TODO: File bugs and blueprints.  Fix that Tomboy/Notes bug.
[15:13] <CardinalFang> BLOCKED: None.
[15:13] <CardinalFang> jblount, what do you see, from there on the summit of Mount Dora?
[15:13] <jblount> DONE: Got my stupid cranky server fixed in the morning, worked on layout bugs
[15:13] <jblount> TODO: Keep hacking on https://bugs.edge.launchpad.net/ubuntuone/+bugs?field.searchtext=&orderby=-importance&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=gd&field.tags_combinator=ANY&search=Search
[15:13] <jblount> BLOCKED: None
[15:13] <jblount> teknico: YOU!
[15:13] <teknico> DONE: more fighting with funambol_cared (#506898); worked on a user's problems accessing the contacts web IU (#506584); started implementing the mobile sync REST API for client app (#504689)
[15:13] <teknico> TODO: land a branch for configuring funambol for sending sms messages (#418048); more work implementing the mobile sync REST API for client app (#504689)
[15:13] <teknico> BLOCK: ubuntuone-storage-protocol misbehaving (#506974)
[15:13] <teknico> next: aquarius
[15:13] <aquarius> ⚀ DONE: spec file delivery downloader daemon; many design discussions
[15:13] <aquarius> ⚁ TODO: redo music store URLs; have music library page send message to downloader daemon and row to database; make workitems of outstanding todo items; make tomboy first-sync experience nicer
[15:13] <aquarius> ⚂ BLOCKED:
[15:13] <aquarius> rodrigo__, go
[15:14] <rodrigo__> • DONE: Contacts picker design discussions with John and Otto. Checked with Ken status of music store packages. Retrieve oauth credentials from keyring in music store widget. Fixed JS code in music store widget. On-call review. CouchdbAuth object in couchdb-glib
[15:14] <rodrigo__> • TODO: Conflict resolver tool in pair tool. Look at becoming a MOTU (https://wiki.ubuntu.com/UbuntuDevelopers). Make sandy's snowy test suite work with our server (http://git.gnome.org/cgit/snowy/tree/api/tests.py). Discuss with jdo and aquarius about oauth token per app, not per machine?
[15:14] <rodrigo__> • BLOCKED: no
[15:14] <rodrigo__> go dobey
[15:14] <dobey> i thought it was jblount's turn again, since he said me twice :P
[15:14] <dobey> ☺ DONE: More testing code for login script
[15:14] <dobey> ☹ TODO: More new UI code and tests
[15:14] <dobey> ☹ BLCK: None.
[15:16] <jblount> (Sorry I'm confusing did everyone get a chance? )
[15:17] <dobey> e'run dat's hur
[15:18] <jblount> well, EOM
[15:23]  * johnlea is back from meeting
[15:25] <urbanape> oh, damn. me:
[15:25] <urbanape> DONE: Finished the green/red flash for the public files UI. Who knows its current state?
[15:25] <urbanape> TODO: Back to Bindwood - migration and subsequent client code paths.
[15:25] <urbanape> BLOCK: None
[15:25] <gourgi> hey jblount i updated my contacts error 500 bug (#506584) with the oopsid ,
[15:26] <jblount> gourgi: Nice, thanks for the update!
[15:26] <teknico> gourgi, thanks, I'll have a look
[15:27] <gourgi> jblount teknico you welcome, tell me if anything more needed
[15:33] <dobey> clearly gweather is confused about what the weather is
[15:33] <dobey> because it is most definitely not raining here.
[15:34] <dobey> at least it's supposed to break 50F today
[15:41] <rodrigo__> adiroiban, I've added the CouchdbAuth object, now for basic auth, you just need to add an 'Authorization' HTTP header, right?
[15:42] <adiroiban> rodrigo_: thank. I will change my code.
[15:42] <rodrigo_> adiroiban, well, wait, we need to define how the auth will be done
[15:42] <rodrigo_> if you just need to add an HTTP header, a 'gchar *add_http_header ()" virtual method would be enough
[15:43] <adiroiban> my path uses the libsoup authentication api
[15:43] <rodrigo_> yeah, I was thinking about just not doing the SoupAuth stuff
[15:43] <adiroiban> and it can be used for basic or digest
[15:44] <rodrigo_> hmm, ok, I guess we'll have to add SoupOauth then
[15:44] <adiroiban> or other http auth
[15:44] <adiroiban> if we want to only support Basic auth
[15:44] <adiroiban> we can have a simple hack
[15:44] <adiroiban> and add the headere
[15:45] <adiroiban> with username and plain text password
[15:45] <adiroiban> but since this is a generic couchdb lib
[15:46] <rodrigo_> yeah, we should support them both
[15:46] <adiroiban> I assume other http auths will be welcomed
[15:46] <aquarius> you can't only support basic auth, since you can't use that for desktopcouch. But supporting basic *and* oauth would be fine, I think
[15:46] <adiroiban> for desktopcouch, oauth is all we need
[15:46] <rodrigo_> aquarius, yes, we are adding basic http auth, oauth already supported
[15:47] <aquarius> rodrigo_, oh right gotcha :)
[15:47] <rodrigo_> just trying to find a good API to support all auth mechanisms
[15:47] <adiroiban> rodrigo_: is simle
[15:47] <adiroiban> use the libsoup api
[15:48] <rodrigo_> yeah, but not sure yet how to fit oauth there
[15:48] <adiroiban> and let developers provide the username and password
[15:48] <rodrigo_> will talk to the libsoup developers
[15:48] <adiroiban> and define a list o prefered auth methods
[15:48] <adiroiban> something like in ssh
[15:49] <dobey> rodrigo_: what about oauth + libsoup?
[15:49] <rodrigo_> dobey, yeah, that's what I'm thinking, adding oauth support to libsoup directly
[15:49] <dobey> rodrigo_: i mean, what's the problem?
[15:49] <rodrigo_> it doesn't support it right now, couchdb-glib just adds an Authorization header
[15:49] <adiroiban> rodrigo_: basicaly my basic http auth code can also be used for the other methods
[15:49] <rodrigo_> dobey, no problem :)
[15:49] <adiroiban> just change the name of the functions
[15:49] <adiroiban> :)
[15:50] <dobey> well, aside from oauth :)
[15:50] <rodrigo_> adiroiban, yeah, but we can't remove oauth support if we use SoupAuth right now
[15:50] <adiroiban> no
[15:50] <adiroiban> there is no oauth support in libsoup
[15:51] <adiroiban> so we need libsoup + custom oauth handling
[15:51] <adiroiban> but handling http auth in libsoup is simple
[15:51] <adiroiban> as you will only need to connect to „authenticate” signal
[15:52] <rodrigo_> yeah, but the "problem" is I want a single auth API, so that you do:
[15:52] <rodrigo_> auth = couchdb_auth_new_oauth|http|whatever....
[15:52] <rodrigo_> couchdb_session_set_auth (session, auth);
[15:53] <rodrigo_> and thus support all auth mechanisms in one call
[15:53] <adiroiban> ok
[15:53] <adiroiban> and what is the current problem
[15:53] <adiroiban> the CouchDBAuth structure
 sure. i'm not totally sure that OAuth fits into SoupAuth though. also, ross burton was looking at this a long time ago and may have done something (possibly in librest?)
[15:54] <adiroiban> could have a : type , user, pass, and auth fields
[15:54] <rodrigo_> adiroiban, yeah, I guess we'll have to do our CouchdbAuth-based stuff
[15:54] <adiroiban> we already have the oauth fields
[15:54] <adiroiban> so we only need to move them in a dedicated structure / class
[15:55] <rodrigo_> adiroiban, yeah, but then what the interface of CouchdbAuth would be, or are you saying to have your soupauth-based code in CouchdbAuth and just have a separated CouchdbOAuthAuth for oauth?
[15:56] <rodrigo_> http://burtonini.com/bzr/soupoauth/
[15:56] <adiroiban> rodrigo_: nope. let me paste the idea
[15:56] <adiroiban> :)
[15:56] <rodrigo_> ok
[16:00] <statik> rodrigo_, have you run jslint on the embedded javascript in your oauth-credentials-from-keyring branch?
[16:00] <rodrigo_> statik, no
[16:02] <statik> rodrigo_, i'm just nervous about how to test the js, and the long term maintenance of it. what would you think about storing the js in a datafile, and reading it in from the file when you need it? then it would be easier to test changes to the js
[16:05] <rodrigo_> statik, yes, that's what I was thinking
[16:05] <rodrigo_> statik, it's in the code right now for easier testing, so that you don't need to install the code anywhere and just run it in the source tree
[16:06] <rodrigo_> statik, but yeah, I'll move it to a file in the next branch, and add jslint tests to the makefile, then, right?
[16:06] <dobey> is there not a good way to run unit tests on js?
[16:06] <statik> dobey: there is, but this branch has javascript embedded in string constants in C files
[16:06] <aquarius> there are semi-good ways -- jsunit, for example -- but it's more complex in the context of JS that expects to be running against a DOM but that isn't in a browser.
[16:06] <statik> which complicates it somewhat
[16:06] <dobey> rodrigo_: for client i split lint and test into separate rules, and added them as dependencies to the check: rule
[16:07] <rodrigo_> dobey, ok
[16:07] <dobey> rodrigo_: so you probably want a jslint rule for jslint, and have check depend on it
[16:12] <adiroiban> rodrigo_: http://etherpad.com/fuhKLBwxMH
[16:13] <adiroiban> basicaly I envisioned a CouchDBAuth class that extend SoupAuth
[16:13] <adiroiban> extends
[16:14] <adiroiban> in SoupAuth we don't have SoupCredentials as it only needs user and password
[16:15] <rodrigo_> adiroiban, I see we might not need CouchdbAuth then, just the credentials,
[16:15] <rodrigo_> the "authenticate" signal can be in CouchdbSession
[16:16] <adiroiban> well
[16:16] <adiroiban> in this case
[16:16] <adiroiban> implementors will not be able to choose fallbacks
[16:17] <adiroiban> of we need to implement an api for fallback
[16:17] <adiroiban> or we will not support fallbacks :)
[16:18] <rodrigo_> and then, how do you pass the correct data to SoupAuth? it only understands username and password
[16:18] <adiroiban> exposing an proxied SoupAuth will allow implementations to behave different based on Realm, but mostly on scheme-name
[16:19] <rodrigo_> hmm
[16:19] <adiroiban> but maybe nowadays
[16:20] <adiroiban> there are not to many apps using Realm and scheme-name
[16:22] <adiroiban> there is one thing that needs to be changed in the current couchdb-glib logic
[16:23] <adiroiban> we need to have make it „react” to couchdb server auth requrest
[16:23] <adiroiban> right now it is pretty dumb
[16:23] <rodrigo_> yes, an "authenticate" signal when there is a 401, right?
[16:23] <adiroiban> if oauth is enabled by the user
[16:23] <adiroiban> oauth will be always used
[16:23] <adiroiban> even if the server does not requires authentication
[16:23] <adiroiban> yes
[16:24] <rodrigo_> well, that code assumes it's desktopcouch
[16:24] <adiroiban> the change should be done in couchdb_send_message
[16:24] <dobey> verterok: ping
[16:24] <verterok> dobey: pong
[16:25] <adiroiban> rodrigo_: oauth is a standard auth method in couchdb?
[16:25] <rodrigo_> adiroiban, yes, not sure if standard, but it comes by default, not enabled though, AFAIK
[16:25] <adiroiban> ok
[16:25] <dobey> verterok: hey. i'm confused about how to make a test fail in the callbacks from dbus
[16:26] <rodrigo_> aquarius, does couchdb support other auth mechanisms by default?
[16:26] <dobey> verterok: i can make it time out, but that's not a useful failure message
[16:26] <aquarius> rodrigo_, only basic auth
[16:26] <aquarius> rodrigo_, and oauth
[16:26] <verterok> dobey: please elaborate :) in which callback from dbus? the error_handler?
[16:27] <dobey> verterok: the signal handler for NewCredentials for example
[16:27] <rodrigo_> adiroiban, ok, so let's see if the whole picture makes sense:
[16:27] <verterok> dobey: could you pastebin the code? or is there a branch I can pull?
[16:27] <urbanape> jblount, well, in any case, I slightly modified it to update the URL both in the fileTable and in the information overlay depending on its status.
[16:28] <dobey> verterok: my test-login branch in tests/test_login.py
[16:28] <urbanape> I've pushed it to lp:~urbanape/ubuntuone-servers/public-files-webui
[16:28] <dobey> verterok: d.callback(False) doesn't do what i thought it did :)
[16:28] <verterok> dobey: ok, gimme 1' to pull
[16:28] <rodrigo_> couchdb tries to send_message and get a 401, in which case it emits a "authenticate" signal?
[16:28] <dobey> and calling d.errback() causes a timeout
[16:29] <rodrigo_> adiroiban, or should it already have a CouchdbAuth associated to it the 1st time it sends_message?
[16:29] <rodrigo_> adiroiban, and call the "authenticate" signal on CouchdbAuth?
[16:30] <adiroiban> rodrigo_: if couchdb will only support basic auth and oauth, we can have the libsoup signal implemented in couchdb-glib and not expose it
[16:30] <verterok> dobey: you want to fire the oauth_denied?
[16:30] <rodrigo_> adiroiban, yes, I'd like to not expose libsoup API in couchdb-glib
[16:30] <dobey> verterok: no, i want to make the test fail if i don't get the signal i'm expecting to get
[16:31] <adiroiban> rodrigo_: then just have CouchDBCredential structure
[16:31] <verterok> dobey: oh, so I you get other signal, e.g: auth_denied is called, you want it to fail?
[16:31] <adiroiban> that can be created both _with_username_and_password and _with_oauth
[16:31] <dobey> verterok: yes
[16:31] <verterok> dobey: d.errback(twisted.python.failure.Failure(Exception('Oops, wrong handler called!')))
[16:32] <adiroiban> rodrigo_: and have couchdb_session_authenticate(CouchDBSession session, CouchDBCredential credentials)
[16:32] <dobey> hmm
[16:32] <verterok> dobey: the other option is to: d.addCallback(lambda r: self.assertTrue(e))
[16:32] <rodrigo_> adiroiban, and when should that be called, when the app using couchdb-glib gets a 401? that is, no management of 401s in couchdb-glib itself?
[16:33] <verterok> dobey: you still call d.callback(False), but check for the callback result
[16:33] <dobey> verterok: the errback just gets me a timeout
[16:33] <adiroiban> rodrigo_: is should be called instead of the current couchdb_enable_oauth
[16:33] <verterok> dobey: could you paste the line of the errback call?
[16:33] <adiroiban> rodrigo_: maybe we can call it couchdb_session_set_authentication(CouchDBSession session, CouchDBCredential credentials)
[16:34] <dobey> verterok: i copied and pasted your paste, into the signal handler method :)
[16:34] <verterok> dobey: hehe, probably a syntax error :)
[16:35] <rodrigo_> adiroiban, and no "authenticate" signal in CouchdbSession?
[16:35] <verterok> dobey: change it to: d.errback(False)
[16:35] <verterok> dobey: in the meantime I'm getting a copy of the branch
[16:35] <dobey> ok that works
[16:35] <adiroiban> rodrigo_: yes. no exposed „authenticate” signal
[16:36] <adiroiban> but we will need to expose a „authentication-failed” signal
[16:36] <verterok> dobey: quite probably a syntax error. you might need to do: from twisted.python import failure and d.errback(failure.Failure(<your failure>))
[16:37] <rodrigo_> adiroiban, yeah, ok
[16:37] <dobey> probably
[16:37] <verterok> dobey: but you can pass anything to an errback, but usually it's a Failure instance :)
[16:37] <rodrigo_> adiroiban, and CouchdbAuth then disappears?
[16:37] <dobey> yeah
[16:38] <adiroiban> rodrigo_: yes
[16:38] <rodrigo_> ok, makes sense to me now, we would just use SoupAuth for the non-oauth mechanisms internally in CouchdbSession
[16:39] <adiroiban> rodrigo_: yes. the implementation should be similar to my code for basic aouth
[16:39] <rodrigo_> yes
[16:40] <adiroiban> just modify couchdb_send_message to also „cry” when oauth is not working
[16:40] <dobey> verterok: thanks again :)
[16:41] <verterok> dobey: np, :)
[16:43] <adiroiban> rodrigo_: yep. it looks a nice API for me. We can call it couchdb_session_enable_authentication
[16:44] <rodrigo_> adiroiban, yes, sounds better than authenticate
[16:44] <adiroiban> rodrigo_: i have updated the ehterpad
[16:44] <rodrigo_> adiroiban, yeah, I can see you typing :D
[16:49] <rodrigo_> adiroiban, instead of _new_with_username_password/_new_with_oauth, wouldn't it look better if we had CouchdbCredentials be username/password based, and then have a separated CredentialsOAuth class?
[16:50] <adiroiban> rodrigo_: I am not sure if we are going to see more authentication schemes, so maybe we can get rid of CouchDBCredential and have couchdb_session_enable_auth_with_user_and_pass and
[16:50] <adiroiban> ouchdb_session_enable_auth_with_oauth
[16:50] <rodrigo_> and enable_auth_with_oauth, yes
[16:50] <rodrigo_> I guess it makes things a lot easier
[16:51] <rodrigo_> and couchdb just supports basic and oauth, so we won't be missing any auth mechanisms
[16:51] <adiroiban> the purpose for CouchdbCredentials is to allow us to add other auth schemes, without changing the existing api
[16:52] <adiroiban> so if couchdb is planned to support other auth schemes
[16:52] <rodrigo_> right, that would make the api be prepared for extension, so maybe it's a good idea after all
[16:52] <adiroiban> it would make sense to have CouchDBCredential
[16:52] <adiroiban> if not couchdb_session_enable_auth_with_user_and_pass and couchdb_session_enable_auth_with_oauth should be fine
[16:54] <adiroiban> I assume oauth and user/password should be fine by now
[16:55] <adiroiban> HTTP Digest and NTML can be implemented using the user and pass api
[16:57] <rodrigo_> adiroiban, yes, let's go with ..Credentials object then
[16:57] <rodrigo_> adiroiban, but the interface between it and ..Session is not clear to me
[16:58] <rodrigo_> adiroiban, should the ...Session object know what to do with each type of credentials? that is, SoupAuth, just add an oauth header, etc?
[16:58] <adiroiban> rodrigo_: yes
[16:59] <adiroiban> rodrigo_: if couchdb will have Kerberos, I would like couchdb-glib to handle kerberos auth for me
[16:59] <adiroiban> rodrigo_: same for an auth scheme based on PKI
[16:59] <adiroiban> rodrigo_: just like it does now for oauth
[17:00] <rodrigo_> well, what I mean is if it the ..Credentials object should do that
[17:00] <adiroiban> rodrigo_: I see Credentials just like an „cached for credentials”
[17:01] <rodrigo_> ok, let's try writing some code...
[17:01] <adiroiban> the session should to the hard work
[17:01] <rodrigo_> adiroiban, I'll add the _oauth stuff and then you can update your branch to add the http stuff, ok
[17:01] <rodrigo_> ?
[17:01] <adiroiban> sure
[17:04] <adiroiban> rodrigo_: regarding the debug branch. I will change the coding style.
[17:04] <adiroiban> but what are the coding convetions?
[17:04] <rodrigo_> adiroiban, gnome-style is called, afaik :)
[17:04] <rodrigo_> do you use emacs?
[17:04] <adiroiban> :)
[17:04] <adiroiban> nope
[17:05] <adiroiban> gedit + vim
[17:05] <adiroiban> but I will look for gnome coding converions
[17:05] <rodrigo_> then, just try to see the rest of the code, and just mimic, I'll shout when you deviate from it :)
[17:05] <adiroiban> for the #undef g_debug
[17:06] <adiroiban> if --disable-debug-messages is pass to ./configure
[17:06] <rodrigo_> ah, right
[17:06] <rodrigo_> ok, update the branch and I'll merge it
[17:06] <adiroiban> g_debug will be defined to Nothing
[17:06] <adiroiban> to avoid wasting some some cpu cycled
[17:07] <adiroiban> it is somehow an „extreme” code optimization
[17:08] <adiroiban> for a simple desktop app with 1000 coucdb docs, it will not make a big difference
[17:09] <adiroiban> if you don't want it, I will remove it
[17:11] <dobey> verterok: bug #506559 looks like something for you?
[17:11] <verterok> dobey: the apple? :)
[17:12] <verterok> dobey: looking
[17:12] <dobey> verterok: it's crashing in _load_pickle in syncdaemon :)
[17:12] <verterok> ouch
[17:12] <verterok> dobey: probably a broken metadata :(
[17:20]  * dobey wonders about this keyring mess a bit
[17:58] <adiroiban> rodrigo_: do we still need DEBUG_OAUTH ?
[17:59] <rodrigo_> adiroiban, yes, I think so
[17:59] <adiroiban> since we have a general DEBUG_MESSAGES
[18:00] <rodrigo_> adiroiban, well, if you replace it with that, yes we can get rid of DEBUG_OAUTH
[18:00] <adiroiban> rodrigo_: I will replace it :)
[18:36]  * CardinalFang is afk to see dentist, today.  Sheesh.
[18:38] <jblount> CardinalFang: Yuck. Good look.
[19:04] <urbanape> jblount, give my branch a look-see and let me know what you think
[19:04] <urbanape> (if you get a few moments)
[19:10] <jblount> urbanape: Yessir, I'll pull it down now.
[19:11] <aquarius> rodrigo_, ping?
[19:12] <urbanape> you the man now, dog
[19:14] <iainhaslam> Hi. Beginner's question I guess, but the FAQ and google didn't help, so here it is: Using ubuntu 9.10, my "Ubuntu One" folder shows different files from the web interface. Q) How can I tell what user account the applet is using?
[19:21] <iainhaslam> I'll add some more info if you don't mind: deleted file in /home/(username)/.config/ubuntuone ; restarted ubuntuone; files in the folder are not synced with the web-displayed folder. I've reloaded the web page (several hours after the applet told me everything was up to date). Is there a common reason for this?
[19:26] <iainhaslam> Hey, sorry for wasting your time. It just started working again, although I'm sure I did exactly the same thing as earlier. Anyway, never mind. (NB probably just deleting that file fixed it, along with removing all currently shared files from the "Ubuntu One Folder). Thanks for your help!
[19:28] <jblount> iainhaslam: You are a hero, I'm glad your problem is sorted!
[19:28] <iainhaslam> jblount: :) Me too
[19:31] <jblount> urbanape: This branch seems to work like we talked about, although I'm still seeing a red flash between clicking "make public" and the page reload.
[19:33] <aquarius> dobey, ping
[19:35] <urbanape> weird. I don't get any red flashes at all.
[19:35] <urbanape> just glorious green
[19:36] <urbanape> even repeatedly clicking the button
[19:36] <urbanape> although, I forgot to make the appropriate changes to the wording, &c.
[19:37] <aquarius> is dobey not around today?
[19:37] <urbanape> he was around earlier
[19:38] <jblount> urbanape: Yeah, I can adjust that stuff. I need to do a bit of css to give things the proper padding and what not.
[19:38] <urbanape> jblount, also, you shouldn't be seeing the page reload
[19:38] <urbanape> it should do it ajaxically
[19:38] <jblount> urbanape: Hrm. I was hoping you would say that.
[19:39]  * urbanape fires up the ol' Firefox.
[19:39] <jblount> Are you pushing to lp:~urbanape/ubuntuone-servers/public-files-webui ?
[19:39] <urbanape> I'd been testing it in Chromium
[19:39] <urbanape> yup
[19:39] <urbanape> lemme make sure I've pushed it all.
[19:39] <jblount> Yeah, that might be it.
[19:39] <urbanape> yeah, it's all there
[19:41] <jblount> urbanape: Wow, this looks great in Chrome!
[19:41] <urbanape> gah
[19:41] <urbanape> yeah, I see the same thing in Firefox.
[19:41] <urbanape> dubya tee eff
[19:45] <urbanape> debugging
[19:45] <urbanape> great, now we're living in a world where Firefox is the throwback.
[19:47] <aquarius> how the mighty are fallen, etc
[19:47] <jblount> Psh, I've been living in that world ever since Safari got awesome.
[19:47] <aquarius> well, when they bring out a Safari port for Ubuntu...
[19:47] <aquarius> ...I still won't run it. :)
[19:48] <aquarius> Chromium's niceness, though
[19:48] <jblount> aquarius: Fair enough :)
[19:49] <jblount> Chromium is super nice. I like that they're brining the focus back to speed.
[19:50] <aquarius> I wish Flash crashed less, although tbh if youtube moved to html5 video and that JavaScript flash port works for noddy games like physicsgames.net and Canabalt, I wouldn't need flash
[19:52] <urbanape> figured it out
[19:52] <urbanape> jblount, the href for the anchor tag needed to be "#", not just ""
[19:52]  * urbanape guesses
[19:52] <urbanape> anyway, seems to work now. I'll commit and push.
[19:53] <jblount> Sweetness.
[19:54] <urbanape> pushed. give it a shot.
[19:57] <jblount> urbanape: This thing rocks like a hurricane. Well done.
[19:58] <urbanape> noice
[19:58] <urbanape> danke
[19:58] <urbanape> there's some sort of nice refactoring that can come out of that
[19:58] <urbanape> but I'm not sure what, just yet.
[20:00] <jblount> So from here, I'll take it and adjust the copy stuff and css stuff and put that noise up for review.
[20:00] <jblount> If we need to put it on zed (currently non-existent) before getting public we cand decide that then.
[20:01] <jblount> That way johnlea + statik + the internet will all be happy and live in harmony.
[20:02] <urbanape> harmonious is good
[20:02] <jblount> :)
[20:07] <urbanape> aquarius, still around?
[20:07] <aquarius> yep
[20:07] <urbanape> do you have a few minutes to talk about db replication?
[20:07] <aquarius> yep
[20:08] <urbanape> so, one thing that bit me quite a bit was u1's version coming back down and imposing itself on my local db.
[20:08] <urbanape> during testing
[20:08] <urbanape> so, I'm embarking on this migration path for existing users
[20:08] <aquarius> ok...
[20:09]  * CardinalFang returns triumphant.
[20:09] <urbanape> apart from live testing it thoroughly with my own data, I'm wondering if I can understand what it will try to do a priori
[20:09] <urbanape> yay, CardinalFang! no cavities?
[20:10] <urbanape> so, if I perform a migration, and change a bunch of records, what's the replication behavior in that case? does it go by sequence number? Since I'll have a boat load of new sequences, will u1 pull those and not try to push back old data?
[20:10] <CardinalFang> urbanape, 34 years, still zero cavities.
[20:11] <aquarius> u1 shouldn't have any changes that aren't local
[20:11] <aquarius> if u1 has changes that your machine doesn't, *and* you have changes that U1 doesn't, then it's conflict city
[20:12] <urbanape> so, I guess what I'd been seeing was a result of me deleting my local db, and starting from scratch, in which case, u1 had some revs that were newer?
[20:12] <urbanape> and getting it into a weird state?
[20:12] <aquarius> yes, or at least I should say that was the problem
[20:13] <urbanape> yeah, okay. cool. so, basically, in a replication network, whichever host has newer sequences will flow to the others? and then what happens with conflicts? one local host has a sequence 55 where one thing changed and another has 55 where something else changed?
[20:14] <aquarius> basically, yeah
[20:20] <aquarius> it's not quite done on sequence numbers, it's done with _rev, but that's the basics of it
[20:21] <urbanape> gotcha
[20:21] <urbanape> that makes sense, since sequence numbers are probably only really pertinent to any given host
[20:21] <aquarius> yep
[20:22] <urbanape> much like the accursed itemIds I deal with inside Firefox
[21:12] <diplo> Hi all, anyone know or point me in the right direction of where i can find a way of integrating ubuntu one/couchdb contacts with thunderbird ?
[21:13] <statik> hi diplo: aquarius or thisfred or chad can tell you all about that. theres a record format defined on freedesktop.org I think, and you could look at launchpad.net/bindwood to see a firefox plugin that talks to desktopcouch
[21:14] <aquarius> hey diplo
[21:15] <diplo> okay thanks, will go take a look, was already thinking of writing a app in python to add contacts as a project as i'm really not a fan of evolution so might as well go the whole hog
[21:16] <aquarius> diplo, the way to do it is to have the Thunderbird addressbook talk to desktopcouch, the user-specific couchdb. As statik says, bindwood is a Firefox extension that talks to desktopcouch (to sync bookmarks), so using similar code would be good -- thunderbird extensions are all XUL and JavaScript the same as firefox ones are
[21:17] <diplo> Great thanks, not created an extension for TB/FF before so will be a good experience
[21:17] <thisfred> diplo: also, the desktopcouch mailing list is a good place to discuss such a project, and to ask questions (here is fine too, of course)
[21:18]  * thisfred looks up url
[21:18] <diplo> heh will do, not even thought about signing up to mailing list
[21:18] <thisfred> diplo:  http://groups.google.com/group/desktop-couchdb
[21:18] <diplo> thanks very much
[21:19] <thisfred> np, it's a very exciting project, I'm sure people will be glad to help. As a thunderbird user, I know I will ;)
[21:19] <voytech> till: Are you there ?
[21:20] <voytech> till: Where can I find qjson sources
[21:20] <diplo> brb sons just got up
[21:20] <aquarius> diplo, the two people who know the most about this area are urbanape (who wrote bindwood, and therefore knows about talking to desktopcouch from inside XUL and with JS) and rodrigo_ (who wrote evolution-couchdb and therefore understands about storing contacts in desktopcouch)
[21:20] <aquarius> diplo, but any of thisfred, CardinalFang, or I can help too :)
[21:29] <urbanape> diplo, I'd be happy to talk about it
[21:29] <urbanape> especially the XPCOM stuff
[21:30] <diplo> Great, sorry just got back... I'm away on a course this week but i think i'll start by going through looking at the other sources first and see how much work is involved
[21:31] <diplo> One other thing i really want is to be able to start integrating this into windows clients as well as with my work 90% of my day has to be on a windows box at the moment
[21:31] <urbanape> if you want to check out bindwood, I'd suggest you look at the stuff I'm doing now. lp:~urbanape/bindwood/manifest
[21:31] <urbanape> there's been a bit of exploration into getting a desktopcouch on Windows
[21:31] <diplo> yeah was reading up on that yesterday
[21:41] <diplo> Seems like there is some good documentation for the couch side, i think the hardest part for me will be doing the FF side :)
[21:54] <urbanape> diplo, keep in touch. I'll try to help as much as I can
[21:54] <diplo> thank you, just having a look through everyones code at the mo
[21:55] <diplo> Will spend some time on it this weekend i think
[22:23]  * jblount may have to stop watching American Idol while working. At least not the try out episodes. 
[22:48] <belacqua> ok, so what is the best way to resolve u1conflicts?   I'm not sure I understand when they are generated either.
[22:50] <diplo> thisfred, aquarius and urbanape, thanks for all your input and help, spent the last hour or so reading up and it looks good. Will add the channel in favs and try and make a start. Off to bed now though :)
[22:50] <diplo> gn
[22:53] <thisfred> later diplo!