hyperblast / beefweb Goto Github PK

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

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

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

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>

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.

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.

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

This could be used to implement authorization, caching etc.

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 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.

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.

• 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 would simplify building with system library if desired.
This library is very small. Linking it statically should not increase binary size too much.

The following look good

• 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

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.

Depends on #27

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.

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)

Steps to reproduce:

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

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

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

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