12:02 <popey> #startmeeting Dekko Meeting
12:02 <meetingology> 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 <meetingology> 
12:02 <meetingology> Available commands: action commands idea info link nick
12:02 <dpm> mardy and ralsina around?
12:02 <dpm> pinged mardy
12:02 * popey pokes them
12:03 <dpm> ok
12:03 <popey> hey mardy
12:03 <DanChapman> Hey boren o/ didn't see you was here
12:03 <boren> hey
12:04 <popey> So the first topic of conversation is UOA integration. Where are we, and what needs to be done?
12:05 <popey> Who wants to go first? Don't all rush!
12:05 <DanChapman> 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 <DanChapman> Also how will our autoconfig steps work in a UOA provider
12:06 <dpm> DanChapman, would that mean an intrusive patch against the trojita backend?
12:07 <DanChapman> dpm nope none at all. Our accounts API is layered on top of it
12:07 <dpm> ok, cool
12:08 <dpm> mardy, any ideas on how the e-mail settings autoconfig that dekko does could work in conjunction with UOA?
12:08 <mardy> So, AFAIU, you'd need only one provider file
12:09 <DanChapman> 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 <mardy> then, all the settings (host name, port, ssl config, etc) should be stored in the account, when you create it
12:09 <mardy> 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 <dpm> oh, I see, the provider would have keys for each one of the settings, which would be pre-set
12:10 <mardy> dpm: well, that's a choice that you can make:
12:10 <mardy> 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 <mardy> dpm: and/or provide a set of .provider files for the most common account providers
12:11 <mardy> dpm: such as yahoo, m$, and others
12:12 <dpm> 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 <mardy> 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 <dpm> Or should we try to provide as many 3rd party providers as we can?
12:13 <mardy> dpm: let me see if I have already written that somewhere...
12:13 <DanChapman> mardy, yes we would use the  XOAUTH2 extensions and we would have to do the same for outlook as well.
12:14 <DanChapman> AFAIK they are the only two major services that implement oauth2 access over IMAP
12:14 <mardy> so, when you call account->value() (or the equivalent from QML), the lib does:
12:14 <mardy> 1) if the key is stored in the accounts sqlite DB, return the value from there
12:15 <mardy> 2) if not, read the .service file, and see if the key has a value in there
12:15 <mardy> 3) if not, read the .provider file, and see if the key has a value in there
12:16 <mardy> 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 <mardy> then, you could ship .providers file for the most common account providers, and not allow the user to change the values
12:17 <mardy> for GMail, you would ship a *.service* file with the GMail parameters
12:17 <mardy> then Dekko wouldn't need to care where the values are coming from, it would just use whatever account->value() returns
12:18 <DanChapman> mardy, ok cool. That sounds reasonable to me.
12:20 <DanChapman> mardy: can we run our autoconfig helpers from the account plugin during account setup?
12:20 <mardy> 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 <mardy> DanChapman: can you give me a link to the current code of these helpers?
12:20 <DanChapman> https://bitbucket.org/dekkoproject/dekko/src/6f28680bf2693710db0172de35710e3c6caf3d0b/src/app/MailConfig/AutoConfig.h?at=devel
12:22 <DanChapman> Is does a thunderbird style walk trying to find the WELLKNOWN host credentials and a final lookup  in mozilla ISPDB
12:22 <DanChapman> based on users email domain
12:23 <mardy> DanChapman: so, the account plugin is QML, but it can import a C++ module (the evernote account plugin does that)
12:24 <DanChapman> mardy: ahh ok, super! I will take a look at that then.
12:26 <DanChapman> boren, can you see any problems with using UOA as our account store and just drop our current store?
12:29 <noise][1> hi, sorry I'm late
12:29 <boren> DanChapman: It looks good.
12:29 <mardy> 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 <DanChapman> mardy, we do allow it to be modified atm
12:30 <noise][1> re: oauth for imap - is that just using the token in lieu of password, so no difference for connecting/polling?
12:30 <mardy> 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 <mardy> 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 <DanChapman> 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 <mardy> or email address, better
12:31 <mardy> DanChapman: yes, that would be wise
12:33 <DanChapman> 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 <noise][1> DanChapman: hmm, we'll have to check if the go-imap lib will handle that
12:33 <DanChapman> maybe icloud aswell?
12:34 <noise][1> looks like not on first check, we can look into it though
12:36 <noise][1> 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 <verterok> 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 <popey> Just noting that we're over time, but we have 20 mins before next meeting if you guys need to continue.
12:38 <faenil> :)
12:39 <mardy> noise][1: verterok is correct
12:39 <noise][1> so we set "service" to "imap" for all the mail accounts
12:39 <noise][1> ok
12:39 <noise][1> 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 <mardy> noise][1: not exactly: dekko will ship an .application file, which will list all the services it supports
12:40 <noise][1> mardy: but polld shouldn't know anything about dekko directly
12:41 <mardy> noise][1: well, it needs to somehow know which accounts it has to poll
12:41 <noise][1> we want to just find imap accts, poll them, and notify the owning app
12:41 <mardy> noise][1: and how
12:41 <noise][1> mardy: right, that's why i was asking if we could query by account "type" or something similar
12:43 <mardy> noise][1: yes, that's also possible. There is a "<type>" element in the .service files, dekko could set that to "imap" or whatherev
12:43 <noise][1> ok, that would be ideal, we want the polld mechanism to be app agnostic in this case
12:44 <mardy> 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 <mardy> noise][1: like the hostname, the port, ssl settings, etc.
12:44 <noise][1> mardy: yup
12:45 <DanChapman> ok, sounds good to me.
12:45 <verterok> 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 <noise][1> correct, and looks like that is provided, looking at the docs linked above
12:47 <verterok> noise][1: not sure if we get appid in the account info
12:47 <verterok> mardy: ^ do you know?
12:47 <mardy> noise][1: well, it's provided, it's just that unfortunately there is no API to read that
12:47 <mardy> noise][1: I think it's better if the account plugin explicitly writes the app-id on the account
12:47 <mardy> when it creates it
12:47 <noise][1> mardy: oh, can we cheat and dupe it on a field
12:48 <mardy> noise][1: exactly that :-)
12:48 <noise][1> +1
12:48 <noise][1> ok, sounds like we have a decent basis of a plan forming :)
12:48 <mardy> 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 <mardy> noise][1: the service Id itself will be the app id
12:49 <mardy> in the unversioned form: <package>_<app>
12:51 <noise][1> alright, anything else to cover right now? DanChapman?
12:51 <DanChapman> 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 <popey> that makes sense, or take it to #dekko after
12:52 <DanChapman> noise][1: no not right now. I'll give you a ping if I have anything else. :-)
12:52 <noise][1> cool, just joined #dekko too
12:52 <noise][1> thx everyone!
12:52 <JMulholland> feel free to drop me a mail dan, ofc!
12:53 <DanChapman> Thanks guys
12:53 <popey> Do we have bugs / work items etc for the above items?
12:53 <popey> :)
12:54 <DanChapman> :-) Well I will be sorting UOA stuff on dekko side. While boren does his magic on addressbook support
12:55 <popey> :)
12:55 <popey> Ok.
12:55 <popey> Anything else before we wrap?
12:56 <DanChapman> Not for me today
12:56 <boren> Not for me
12:57 <noise][1> All set, we'll be getting started on the polld side as soon as we can
12:57 <popey> Great. Thanks guys, and thanks noise][1 mardy verterok for joining!
12:57 <popey> #endmeeting