Information from here: https://github.com/deltachat/provider-overview/tree/master/_providers should be shown when the login fails, instead of the generic message “Some providers put information in the inbox” (about that). I could try to implement this myself if you approve.
Obviously, the first question is: Where should I implement it? In dc-android? dc-core? dc-core-rust?
I would say to show a button/ dialog that suggests you to search on the provider overview page.
Also we could provide a stripped doen version of the provider list with each release:
Config/Login Fails → provider is in this list known to not work out of the box → show link to provider overview (page that contains the steps)
I do not know… This does not sound very userfriendly to me. I’m afraid that quite some users will quit if you point them to a website and tell them “Go look for help there”. At least I would, if I didn’t hate WhatsApp so much.
A support bot can then lookup there the users provider that asks for help.
Maybe I misunderstood you but - the user can’t chat with a bot if they could not login.
And again, I am willing to help with this and send a PR.
Anyway, what I forgot to say: Thank you for your answer! 
The issue “is” general and can also be used for this not only a support bot, even if I only mentioned a support bot.
We shouldn’t forget to ask the user when we connect/redict to any internet site - so he can decide - because privacy and so on
You’re welcome also hit me up if you want such an “api”, though the provider overview isn’t online yet because we didn’t got to giving it a (sub)domain yet.
Ok, that’s a point (although probably most users await that a chat app will connect to a server, even without asking). Another idea: Bundle the overview with DC as an asset (the _providers folder is less than 150 KB).
Yep,
Shipping the “problem–>solution” info (only for providers with actual problems) actually allows to avoid errors, by displaying the info in the configuration dialog for the known providers even before making a connection attempt.
And it allows the app to be usable with just email connectivity (firewall).
Very good.
Ok we need a list of providers that have needsPreperation:true or Status not ok.
We’ll include only following properties:
- name
- website
- credentials
- needsPreperation
- status
- markdown content (everything beneeth the yaml font matter) without media/images (stripped down version)
150 KB
It’ll get a bit bigger after the content is converted to html, also don’t forgot that the most guides to getting it working aren’t very detailed yet.
Also show the user a button to open the full page on the provider overview. (( because it could contain a guide with video/screenshots later on))
Did I forget anything?
I do not think so.
Is there any script that gets executed every time DC gets an update? In that case, I could write one that generates this list.
Again, do you think that it should be in the core or dc-android?
It’s needed on all platforms, so -core sounds like a benefit.
(The basic multi-account is also in core.)
The Provider overview is made with jekyll - a static website generator, I think I can add a site/endpoint that combinds/generates this data, so the release update/script only had to pull some file like https://providers.delta.chat/setupinfo.json or rather .xml?
Anyways lets talk about formats and structure then I can add a page like that.
I also still need to ask @hpk what he thinks domain-wise and then we can put up the (alpha) provider overview.
Is http://providers.delta.chat/data.xml ok/enough to work with?
We still think about moving the needs preparation column to status so this isn’t the final format.
The Liquid Template language is limited, so html cleanup would be have to be done manually.
The update script for dcc-rs would need to fetch the document and (optionally) minify it to safe space. I choose xml as format because we’ll have a xml parser in dcc-rs anyway (https://github.com/deltachat/deltachat-core-rust/issues/47).
A note on http://providers.delta.chat - The site is still in an early state so please don’t do big announcements until it looks presentable.
Looks good, thanks! What I just noticed when I looked at data.xml: XML is a format that has a lot of “redundant” characters, maybe this could be fixed by making the tags shorter (<pr> instead of <provider>); either in the original xml file or when it is put into dcc-rs. Or we choose a very simple format like
provider.de:Necessary preparations
provider2.net:Preparations for provider2
and a simple list for providers that do not work at all (works=false). Any opinions?
Is data.xml going to be the new “source” or is it generated somehow as well?
And what language can the update script be in? Bash?
Finally, what do you mean with
?
Maybe we can zip/compress it when putting it in dc…
Or we choose a different format that is smaller.
we can also do that.
We (will) have an xml parser in rust core so I think xml is a good format for it.
It’s generated from _providers and it’s source is https://github.com/deltachat/provider-overview/blob/master/data.xml.template
Bash is fine, if its possible I think rust would be awesome, but I don’t know enough about it to tell if it is possible.
By html I mean the rendered markdown in <content>, (later) removing image tags, removing/replacing tags like this construct:
<div class="highlighter-rouge">
<div class="highlight">
<pre class="highlight">
<code>
IMAP newyear.aktivix.org:143
SMTP newyear.aktivix.org:25
sec: STARTTLS
</code>
</pre>
</div>
</div>
can be shortened to
<code>
IMAP newyear.aktivix.org:143
SMTP newyear.aktivix.org:25
sec: STARTTLS
</code>
and we can use some css on the display side to make the effect of the code box.
There should be an script to update the translations, there is one in dc desktop, I don’t know how it is exactly done in the rust core.
Rust would probably be possible but lots of extra work because it is not meant do be a scripting language. Also the script would probably become unnecessarily long and unreadable.
Could you tell me how exactly you are generating the xml file with jekyll (what script/command/options you use)?
Could you tell me how exactly you are generating the xml file with jekyll (what script/command/options you use)?
See the github link I send in the last post
@Hocuri https://github.com/deltachat/provider-overview/pull/16
can you take a look at it? and maybe improve it?