search

aceinnolab / Inkycal

Create awesome e-paper dashboards within minutes! Modularity? Check! Python3? Check? Works on Raspberry Pi Zero W? Check! Support for own modules? Check!
https://aceinnolab.github.io/Inkycal/
GNU General Public License v3.0
1.21k stars 128 forks source link

[FEATURE]: built-in web server #292

Open lukasMega opened 11 months ago

lukasMega commented 11 months ago

Is your feature request related to a problem? Please describe. Provide simple HTTP API (built-in web server) to render image(s)

Describe the solution you'd like Firstly, it's more a question like feature request. Have you ever considered implementing a simple web server that with REST API (does not require a web UI)?

Describe alternatives you've considered -

Additional context -

Purpose: from other device (PC/server) in LAN via HTTP request send/upload an image to Inkycal device.

for example: POST /inkycal/render-image:

Later it can be extended:

for example status endpoint:

GET /inkycal/status:

   { 
        "running": true, 
        "idle": true, 
        "nextRenderAt": "2023-12-09 23:30:00", 
        "lastRenderAt": "..." 
    }
aceisace commented 11 months ago

This is an interesting feature indeed @lukasMega . Having an integrated web-ui would be a great convenience for users. Implementing a REST API is pretty simple and I have done it in a recent project too, but if such a feature is wanted by the community, I want to choose an approach which is easy enough even for beginners, which would be a fully-fledged web-ui.

InkycalOS (not Lite), which was released as a beta actually has all the functionality. However, maintaining the web-ui is pretty hard due to the following reasons:

Until all of these things have not been considered, it makes sense to stick to the current approach, a web-ui in standalone mode. If you know an approach to fix these issues, please let me know.

The web-ui served over my website is actually fully independent of Inkycal. The drawback is that I have to update everything manually (which fortunately is rare anyway), but the good thing is that it is backwards-compatible in most cases and less prone to errors as everything is hard-coded. The Web-UI knows exactly what each module needs and renders a pre-defined HTML element

lukasMega commented 11 months ago

Hello! I don't see a big problem with that. 🤷 This is probably because I'm not familiar with the code and the architecture.

How are parameters from an inkycal module "translated" into the web-ui? HTML only supports text, numbers and files. Consider the case to add multiple icalendar URLs.

  • firstly, it can be simply a json (with some schema validation on the client side)

What happens if I (accidentally) delete a inkycal module?

  • I do not fully understand this. Delete module from configuration? Or delete some python dependency needed for particular module?
  • For first case it should behave like in yourl WEB-UI https://aceinnolab.com/inkycal/ui

How can Inkycal validate the parameters before a settings.json file can be generated to ensure mistakes are caught in advance?

How can new modules be added to Inkycal?

  • I don't know what you mean exactly. If you will develop new feature and in new version?

How can the python modules read back data from the settings.json file into the Web-UI?

  • How is that done now? I suppose that settings.json is loaded once when app is starting.
  • Before complicating it with some run-time loading, it can be easily done when existing Inkycal application will remain standalone and web server will be able to start / stop / restart the Inkycal application.

So basically every new Inkycal version will provide it's own WEB-UI which will be 100% compatibile and you can do later breaking changes without thinking about preserving backwards-compatibility.

Another user friendly feature came to my mind - some list / gallery of predefined configurations (templates) so user can choose quickly which template he likes and then he fill only missing pieces of configuration.

Maybe one day I'll develop what I'm missing myself.

aceisace commented 11 months ago

Inkycal is made modular and written as a library and is installed in such a way that editing the original files causes these changes to be reflected on the next run. It's actually a lot more complicated as not only are there several modules, but also several drivers, tests etc. It's therefore not easy implementing a task which would require changes in every module.

Right now, the web-ui's HTML-files has hardcoded configuration for every module. Each module's parameters and datatypes are already integrated to the web-ui. Even with a python-based server, fetching what exactly each module needs, what is optional and what is required is quite a challenge. A translating tool is required, fetching all the config from every module and its datatype and whether or not this is required or optional and how to render it as HTML (dropdown, text, select, checkbox, number) With InkycalOS-Beta, this was implemented with a custom format, which proved to be too difficult to maintain and was absolutely not according to python standards. As a result, it is now being deprecated and will be removed in the next release.

If we can implement a stable solution to fetch all parameters from the init function of a python class, 30% of the work is already done. I've been looking for a suitable solution, but was unable to find one. If you can find some resources about it, I will give it a try. Until then, this feature has to remain on hold. Again, if you know anything which could be useful, please share them here.

Hint: Websites work well with JSON-Format. If you can find a tool/code translating the parameters of the init function of a python class into JSON, this should be enough to get this started at least