12:02 #startmeeting Dekko Meeting 12:02 Meeting started Thu Apr 23 12:02:12 2015 UTC. The chair is popey. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 12:02 12:02 Available commands: action commands idea info link nick 12:02 mardy and ralsina around? 12:02 pinged mardy 12:02 * popey pokes them 12:03 ok 12:03 hey mardy 12:03 Hey boren o/ didn't see you was here 12:03 hey 12:04 So the first topic of conversation is UOA integration. Where are we, and what needs to be done? 12:05 Who wants to go first? Don't all rush! 12:05 Right so my thinking atm, with the recent talks about notifications is that all our accounts will need to be stored in UOA. So that means dropping our current internal backend. But we need to come up with IMAP providers that work for polld 12:06 Also how will our autoconfig steps work in a UOA provider 12:06 DanChapman, would that mean an intrusive patch against the trojita backend? 12:07 dpm nope none at all. Our accounts API is layered on top of it 12:07 ok, cool 12:08 mardy, any ideas on how the e-mail settings autoconfig that dekko does could work in conjunction with UOA? 12:08 So, AFAIU, you'd need only one provider file 12:09 mardy can we in dekko create an account and do our own autoconfig stuff and then once we have all the details submit it to UOA rather than do the configuration in UOA system settings or where ever it comes from? 12:09 then, all the settings (host name, port, ssl config, etc) should be stored in the account, when you create it 12:09 DanChapman: unfortunately not, because of app confinement: confined apps cannot write to the accounts DB (but account plugins can) 12:09 * DanChapman needs to re-read the docs on it again 12:10 oh, I see, the provider would have keys for each one of the settings, which would be pre-set 12:10 dpm: well, that's a choice that you can make: 12:10 dpm: you can have a very generic .provider file, with no settings at all (of just default settings, but which can be overriden), 12:11 dpm: and/or provide a set of .provider files for the most common account providers 12:11 dpm: such as yahoo, m$, and others 12:12 mardy, so for e.g. gmail & co we'd have the settings already pre-set in the provider, but for a generic account, how could the override work? 12:12 also, keep in mind that GMail could/should be handled differently: for it we already have an account plugin, it would be nice if you could use the oauth token to authenticate to IMAP 12:12 Or should we try to provide as many 3rd party providers as we can? 12:13 dpm: let me see if I have already written that somewhere... 12:13 mardy, yes we would use the XOAUTH2 extensions and we would have to do the same for outlook as well. 12:14 AFAIK they are the only two major services that implement oauth2 access over IMAP 12:14 so, when you call account->value() (or the equivalent from QML), the lib does: 12:14 1) if the key is stored in the accounts sqlite DB, return the value from there 12:15 2) if not, read the .service file, and see if the key has a value in there 12:15 3) if not, read the .provider file, and see if the key has a value in there 12:16 so, for a generic IMAP account, you could ship an account plugin with a .provider file with default values, but allow the user to change them 12:16 then, you could ship .providers file for the most common account providers, and not allow the user to change the values 12:17 for GMail, you would ship a *.service* file with the GMail parameters 12:17 then Dekko wouldn't need to care where the values are coming from, it would just use whatever account->value() returns 12:18 mardy, ok cool. That sounds reasonable to me. 12:20 mardy: can we run our autoconfig helpers from the account plugin during account setup? 12:20 DanChapman: as for how to create the account, you could show in Dekko a list of the supported providers, and when the user taps on one, you would use the Ubuntu.OnlineAccounts.Client API to request the creation of an account of that type 12:20 DanChapman: can you give me a link to the current code of these helpers? 12:20 https://bitbucket.org/dekkoproject/dekko/src/6f28680bf2693710db0172de35710e3c6caf3d0b/src/app/MailConfig/AutoConfig.h?at=devel 12:22 Is does a thunderbird style walk trying to find the WELLKNOWN host credentials and a final lookup in mozilla ISPDB 12:22 based on users email domain 12:23 DanChapman: so, the account plugin is QML, but it can import a C++ module (the evernote account plugin does that) 12:24 mardy: ahh ok, super! I will take a look at that then. 12:26 boren, can you see any problems with using UOA as our account store and just drop our current store? 12:29 hi, sorry I'm late 12:29 DanChapman: It looks good. 12:29 DanChapman: one problem could be, if you need to modify the store after the account has been created; do you ever do that? 12:30 mardy, we do allow it to be modified atm 12:30 re: oauth for imap - is that just using the token in lieu of password, so no difference for connecting/polling? 12:30 DanChapman: like, if the user wants to have a different signature for different accounts, and you want to let them modify this at any time 12:31 DanChapman: if that's the case, this data should be stored in some other location where dekko has write access, and maybe index it via the account ID 12:31 mardy, ahh signature etc I would keep out of UOA as that's probably more a local settings. I'm thinking UOA would only store what's required to connect & authenticate 12:31 or email address, better 12:31 DanChapman: yes, that would be wise 12:33 noise][1: oauth for imap is only implemented by gmail & outlook AFAIK in widespread use. And you have to use the AUTHENTICATE command something like "AUTHENTICATE AUTH=XOAUTH2 *token*" instead of LOGIN *username* *password* 12:33 DanChapman: hmm, we'll have to check if the go-imap lib will handle that 12:33 maybe icloud aswell? 12:34 looks like not on first check, we can look into it though 12:36 mardy: from the polld side, how we can check UOA to "get all IMAP accounts", and do they come with the appId of the app that created them? 12:37 mardy, noise][1: if I understand the docs correctly, we can filter accounts by applicationid: https://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.OnlineAccounts.AccountServiceModel/#applicationId-prop 12:38 Just noting that we're over time, but we have 20 mins before next meeting if you guys need to continue. 12:38 :) 12:39 noise][1: verterok is correct 12:39 so we set "service" to "imap" for all the mail accounts 12:39 ok 12:39 also, can/should we include a "shouldPoll" flag in the accounts, so a user can choose if a particular account should be polled? 12:39 noise][1: not exactly: dekko will ship an .application file, which will list all the services it supports 12:40 mardy: but polld shouldn't know anything about dekko directly 12:41 noise][1: well, it needs to somehow know which accounts it has to poll 12:41 we want to just find imap accts, poll them, and notify the owning app 12:41 noise][1: and how 12:41 mardy: right, that's why i was asking if we could query by account "type" or something similar 12:43 noise][1: yes, that's also possible. There is a "" element in the .service files, dekko could set that to "imap" or whatherev 12:43 ok, that would be ideal, we want the polld mechanism to be app agnostic in this case 12:44 noise][1: just be aware that this also means that you must somehow standardize on what fields you expect to find in the account 12:44 noise][1: like the hostname, the port, ssl settings, etc. 12:44 mardy: yup 12:45 ok, sounds good to me. 12:45 noise][1: polld would need to also get the appid from the account, right? in order to send the signal to the app helper (besides all the IMAP connection data) 12:46 correct, and looks like that is provided, looking at the docs linked above 12:47 noise][1: not sure if we get appid in the account info 12:47 mardy: ^ do you know? 12:47 noise][1: well, it's provided, it's just that unfortunately there is no API to read that 12:47 noise][1: I think it's better if the account plugin explicitly writes the app-id on the account 12:47 when it creates it 12:47 mardy: oh, can we cheat and dupe it on a field 12:48 noise][1: exactly that :-) 12:48 +1 12:48 ok, sounds like we have a decent basis of a plan forming :) 12:48 noise][1: ah, well! actually, our click hoor renames the .service files according to the app-id, so you don't even need to read a field 12:49 noise][1: the service Id itself will be the app id 12:49 in the unversioned form: _ 12:51 alright, anything else to cover right now? DanChapman? 12:51 JMulholland: I have some questions about our current setup process with these changes. Shall I just ping you an mail with my questions? As we are out of time here 12:51 that makes sense, or take it to #dekko after 12:52 noise][1: no not right now. I'll give you a ping if I have anything else. :-) 12:52 cool, just joined #dekko too 12:52 thx everyone! 12:52 feel free to drop me a mail dan, ofc! 12:53 Thanks guys 12:53 Do we have bugs / work items etc for the above items? 12:53 :) 12:54 :-) Well I will be sorting UOA stuff on dekko side. While boren does his magic on addressbook support 12:55 :) 12:55 Ok. 12:55 Anything else before we wrap? 12:56 Not for me today 12:56 Not for me 12:57 All set, we'll be getting started on the polld side as soon as we can 12:57 Great. Thanks guys, and thanks noise][1 mardy verterok for joining! 12:57 #endmeeting