i have to clarify my post from above: while i still think, it is a nice overview of possibilities, i think it is actually a bit too much we can really take care for. i think, esp. in the first time, we have to maintain the database, at least for the bigger providers, ourself.
i would reduce the database strictly to what we really need in the first step in the app.
also, i would add dedicated, separate fields only as really needed - classifying everything is a table sounds nice and correct, however, in practice, all these nice classifications often do not work out and you need even more fields.
so, my suggestion is: separate fields only for things actually proven to be needed by the apps, the rest can go to a freetext field.
---
name: Example Provider
state: [OK | PREPARATION | BROKEN]
domains:
- example.org
servers:
- type: imap
socket: SSL
hostname: imap.example.org
port: 123
username: defaults to email address
- type: imap
socket: STARTTLS
hostname: imap.example.org
port: 456
username: defaults to email address
- type: smtp
socket: SSL
hostname: smtp.example.org
port: 789
username: defaults to email address
before_login_hint:
optional text that is be displayed before the user logs in
typically in combination with state=PREPARATION or state=BROKEN
after_login_hint: optional,
text that is added to the device chat after login
date: [optional, YYYY-MM]
website: [optional, website of the provider]
---
[optional markdown that descripes the preperation steps, this gets displayed on the website]
PREPARATION means steps needed to be done by the user that cannot be done automatically.
all fields but name, state and domains are optional. however, in practice, either at least servers or before_login_hint will be specified to make some sense.
minimal json-format example that gets to the ui:
{
"state": "PREPARATION",
"before_login_hint": "please create an app-specific password"
}
the other fields are needed by the core only, eg. servers is used to login, after_login_hint adds a message to the device chat. no need for the ui to care about this.
Server should be optional in the yaml, as it will overwrite thunderbirds data.
I like the seperation of date from the state as this makes the data structure more flat.
The optional fields were ~ in my pr, because thats what the serde yaml parser understands easily.
Also iIwould not make the date optional, its useful for the ui to know how long ago the last check was to hint the user to look at the website instead if its older than x days, though that would require us to update the status regularly, wouldn’t it?
yip, the server section can be optional. also as eg. for outlook we would just say “broken” - or for maybe gmx the server-settings work out of the box (so the defaults probed as now) but we want to say “prepare”.
wrt date: eg. the thunderbird database has no date, so, at least in the core, there will be many cases without a date. also, i do not think that this is super-useful, esp. as it is easily badly maintained. maybe we should just show the date from git on the website and that’s it. but this is nothing really important currently.
Nope, website just refers to the providers homepage.
The data structure saved in the fontmatter yaml is not exactly what the provider crate will expose, see https://github.com/deltachat/provider-db/blob/47beeb1db20db28479706fd34ac7ca27937cb95a/src/provider.rs#L23-L32
for what is actually saved and exposed to the ui (keep in mind that this file is from my “old” saturday-morning pr, where you guys only revied the readme as far as I can tell.)
It would be most helpful if you could check out the Vodafone settings by entering them manually. If Delta Chat works successfully using these settings, they can be implemented in the database. Please let us know about it, thank you.
