A number of folks, myself included, have been dismayed, limited, or otherwise surprised at the decision to require the use of Starlark in developing applications for TidByt.
Here are a few examples of posts referencing this sentiment:
- Zapier Integration
- Announcing Pixbyt: a self-hosted app server for advanced apps - Developers - Tidbyt
- Using Pillow and Python for generating the WEBP file - Developers - Tidbyt
- StarLark Failing
- Aircraft/Flight Number Ident - Feature Requests - Tidbyt
- Custom Module to Re-use Code - Developers - Tidbyt
My thoughts on something that may be very powerful, and beneficial to the quality of the applications on the app store is essentially an API that allows developers to receive HTTP data about a user (their configuration provided in the Starlark schema), render the image externally from the Tidbyt server which then delivers a POST request with the appropriate information, and the server responds with the correct .webp image for a user.
I asterisk this that I have just started looking into developing for the TidByt and some of these assumptions I suggest this design with may not be valid.
TL;DR: The suggestion is to create an interface option when creating an application to give developers a web address where the developer’s server owns the rendering logic for the user’s Tidbyt and returns it to the tidbyt server, who can then cache, etc.
The business case for the Tidbyt team to pursue this is as follows:
- More applications developed by 3rd party developers.
- Higher quality applications (see: Delete Apps That Don’t Work) since developers can use their language of choice.
- Less stress on the Tidbyt servers (and as a result, lower costs).