Separate reception of records and display of record data
Form an email from Pim Schellart:
This links back to a discussion we had a while back. How much client infrastructure do we want to support? We could make clients keep a backlog of things to send and then resend them once the server comes back online. But that would involve writing an actual client implementation. Something that Thomas now seems to be doing. And once you go down that path it doesn’t take long before we end up saying to observatories: “in order to work with our system you will need to install this massive software package / framework and do things `our way’” which is exactly what we want to avoid. Unfortunately staying light weight on the client side means staying light on features as well.
Actually one elegant way of handling this would be to have the server consist of two parts. One that receives RPC requests (without knowing much about them) puts them in a queue and forwards them. And the other being the actual server with all the logic. Then we can bring the latter part down for upgrades while still receiving client connections.
Of course then the website will appear unresponsive to users sending metadata (i.e. they don’t see their stuff coming online) but for a short restart that should be ok.