This would prevent stucking of event streams when the device is suspended or otherwise looses connection. Automatic reconnection is assumed to be done by browser, but apparently some issues exist.

Since libevhtp development is back to live, probably it's worth keeping up with the upstream.

Actual UX (especially for mobile devices) is to be figured out yet.
We could support check boxes or long taps to enable selection mode or both or whatever.

Those are domain specific, Server component should have it's own configuration

Considering we already use nodejs for building client using it for API tests would not introduce additional dependencies.

This would simplify building with system library if desired.
This library is very small. Linking it statically should not increase binary size too much.

Some libraries have stable API and are generally available.
We should provide an option to use some libraries from system, but build the rest via CMake external projects.

Swagger currently does not support that, but we still can add it somehow.
Probably pretend to be regular JSON, but describe actual behavior in comments.

We could use axios library and some import/export magic to make this work.

This has several advantages over existing solution:

• Single implementation for all platforms
• Nothing to build because library is header-only and we already using boost
• Supports web sockets
• No special configuration is required for Windows platform (unlike HTTP server API and its URL reservations)

Currently we use seconds when dumping player status (e.g. current track duration, position).
However when changing current position milliseconds are used.

• Minimally builds on Windows with MSVC
• Platform specific functions are implemented
• HTTP server is implemented
• Continuous integration via AppVeyor or other service
• Final clean up

This could be used to implement authorization, caching etc.

The following look good

Depends on #27

Error:

[warn] evbuffer_add_file: mmap(14, 0, 0) failed: Invalid argument

Similar bug in libevent: libevent/libevent#306

Since we use this to send static files web UI is unusable until this is fixed.

We should reference playlist items rather than file names on disk, e.g.

/api/artwork/:plref/:item

If no artwork was found default artwork should be provided unless overridden by ?allowDefault=false

Default artwork should be available via explicit query:

/api/artwork/default

This would allow users to try our work before we have stable releases.

Steps to reproduce:

• Start playback
• Switch to playlist browser
• Try to switch back
• Nothing happens, error is displayed in console

Introduce object model for various setting types (boolean, enum, etc). Those should be self-describing to allow more automatic UI generation. For example setting description, default value, enum names could be defined in setting metadata.

Each setting could be persistent or non-persistent. Second option is useful for global options that are defined by environment. For example "touch support" or "compact UI layout" for small screens.

Persistence should be extracted to separate class. It is useful for testing.

Existing TouchSupport class could be converted to controller that dynamically updates setting depending on browser capabilities.

MediaSizeController similarly should use this new setting model.

Probably we don't need to ways to do the same and stick to one volume control function

Currently paths std::string is converted to Path for validation, then converted back to pass to player API.
We can avoid this by modifying player API to accept something like std::variant<std::string, Path>

• All callbacks should capture this via weak reference
• doPollEventSources() should use work queue of corresponding request handler
• Current async restart model probably could be simplified: if settings are changed server is destroyed and created with new settings