I agree with Asit, but I would go further. You have one thing that is fetching files and putting them in a directory. You have another thing that is exposing the files in a directory via a web interface. Except that they happen to be working on the same directory, there is no connection between the two things. They could run on different machines. My suggestion would be to have two completely separate programs. Then, assuming that the machine(s) they run on stay up, if the file fetcher falls over, the web server will still display the files that are there, and vice-versa.
I did similar things during a project I worked on a couple of years ago, but not using Go. That solution uses a Java web server to display data which is fetched using an off-the shelf FTP server driven by cron scripts running TCL programs. We authenticated the FTP connection using passwords and I recall that one of the challenges was to protect the password from exposure. You could probably cobble together a prototype file fetcher more quickly using a solution like that, but it would be easier to make a Go solution secure. For maximum security, use certificate authentication rather than passwords, but that involves passing certificates around, which can delay getting the thing up and running, especially if there are lots of organisations providing the files. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
