Better handling of static resources

[na--]

Some static resources (like handler/status/templates/status_page.html) have to be embedded in the source code. Otherwise, they may not be available at runtime.
We can embed them manually as strings or use some of the tools mentioned here or write a simple go generate tool of our own.

[ironsmile]

I am not comfortable with this. Not with the embeding of static resources in general but with embeding HTML templates in particular. I have few objections against it:

1. Does it mean that we will have all the static resources in the binary? This will increase the binary size. Go binaries are big enough as it is!
2. It will make editing static pages a pain in the ass. You will have to recompile the binary just to see a tiny little change in a HTML tag. Not to mention that you will have one more step before compiling.
3. It adds complexity to a simple task - rendering a page from a template. Be it a binary bundler or a custom go generate solution.
4. Makes harder customization for 3rd parties. I am sure much more people will be able to customize their server status if it is a static file on the disk.

Neither of the objections is particularly strong, but the same can be said for the benefits of bundling. As far as I can tell they are:

1. Shipping nedomi will be easier as there are less files we will have to worry about.
2. There is absolutely no chance for a runtime or a startup problem due to missing resources.
3. The installer/startup code wouldn't have to deal with working directories, resource directories and such.

I am sure we can leave the static pages in their own files and deal with all the runtime problems at the same time. For example, a template may be compiled only once - at startup. And this is the proper way for dealing with templates. Once started, the server will not need the template file any more. This way we eliminate the runtime problem and only the startup problem remains. I would guess that a message at startup saying something like "Warning: a static resource was missing. Could not open " would be more than enough. The server will still start but "crippled" a bit.

What do you think about it? RFC :)

[na--]

Good points - I agree with both the pros and the cons. I guess it depends on how many static resources we will have eventually. If it's just the status page and a few other simple pages, I still prefer that we make them embeded. If we have a lot of assets, especially ones that are customizable, It will be easier for them to be separate.

And just a note on "template compilation on startup": if we do it this way, changing a single line in the template will require application restart, which may still be annoying, even if there is no compilation.

[ironsmile]

A configuration variable or a command line option can be used to force the server to recompile the templates every time. But I guess the same method can be used when static resources are embeded.

[mstoykov]

First I am more against the change than for it - mostly because the benefit is not so big and the downside is that we will have to have another dependency.

On the other hand:

1. The size of the template (especially gzipped) is negligible.
2. Some of the tools go around this by having two modes one of which is developer in which there is no embedding. This is also true if you decide that you will not recompile the templates all the time.
3. The main problem in my opinion.
4. That might be a problem as well although I don't think this is a feature that we are striving to have.

The proposed solution has problem 2 - I have to restart the server to see a change. I propose the install instruction to point out that if you want to have static files you have to copy them in the working dir.

[ironsmile]

Or we can make nedomi search for the static resources on some predefined places. $GOPATH/src/github.com/ironsmile/..., /etc/nedomi, $HOME/.config/nedomi (for unixes), $APPDATA$\nedomi (for windows) or more. Something like the $PATH resolution.

This way the installer will know where to put the files and the working directory will have no part in the business.

[mstoykov]

that is a good solution or we can have another configuration in the config that is where the static files are.
But for me this is the best and the most standard solution - this is actually the way it's done everywhere else :)

[na--]

👍
In any case, that's something that can definitely wait for after the alpha :)

[ironsmile]

Absolutely true!