Code structure

split App.Zone to improve compilation times
modules should have specific API
maybe have a module with the entire state and a single function handling all state modifications on received message

Also, the Bulma module should be removed. The actual Bulma-related code should be in a package (such as https://github.com/KaneRoot/purescript-bulma, which currently lacks some features). The general style of the website should be in a module.

Features

display a message when the email isn't provided (happens when the account was migrated from dnsmanager v1)
zone-wise indications to help people configure their zone for specific uses (web, mail)
explanations and static content in general should be written using some kind of templates, not directly in Halogen
admin interface: enable administrators to ask for users' info and show zones
admin interface: perform a few more administrative operations (TBD)
allow '*' in record names
allow '@' in record names (replaced by the fqdn, the "root" domain, such as "example.netlib.re.")
enable to change NS records, but after a accepting the consequences

Tests

Check for common errors:

nodes with both a CNAME and another RR
verify that SPF mechanisms point to available records

More specialized tests or debug options:

verify the length of received messages in App.Message.IPC
MAYBE: run named-checkzone on the genetared zone and provide the result in case of an error

Display

user interface: display the email address
somewhat better looking welcome page
somewhat better looking explanation pages
hide logs by default?
maybe notifications should disappear after a few seconds
admin interface: basically just rewrite the whole thing, it's a mess
say that there is no IPv6 on the server at the moment, so there is no point doing IPv6 address updates

General note

The code should be reviewed and a decent documentation should be provided.

Right now, the code is still in a somewhat early stage and multiple refactoring should take place. For example, modules have a very generic API; they can provide or receive messages from (respectively to) authd or dnsmanagerd. Instead, modules should have a more specific API and not deal with message encoding at all. Furthermore, maybe the state of the entire application should be stored in a single module, with a single function handling all state modifications when a message is received, enabling a simpler data management.

TODO in authd and dnsmanagerd

enable users to change their NS
MIGRATION-related: remove migrated accounts with no connection in over 6 months

2.6 KiB Raw Blame History