> But once you have defined and tested your GATTs, it hasn’t been my experience to come back to it a ton of times.
> It was my experience to care more about distance, speed, interval, and MTU on actual hardware than protocol confirmation to a PC.
That's exactly my concern, coupled with a (perceived) small pool of Bluetooth developers. Do you think there's a market for a Postman style commercial cloud product for team collaboration?
I started with TOML but switched to YAML because people are familiar with OpenAPI. Ultimately everything is parsed to a Javascript object so you can have adapters in your favourite spec language.
Hey, thanks for checking out my project. So the spec is independent of Web Bluetooth; like Swagger is to Swagger UI. I considered electron but it needs installation and wouldn't run on mobiles. Perhaps Web Bluetooth is not ready for devices, but is perfect for dev tools like this one.
As of today it can generate an Arduino GATT server; I'm working to support more platforms, Zephyr, iOS etc.
Thanks for the feedback! I'm certainly add a `--user` flag. One kind note though, the service being set up does not have root access. The value of `User=` is $SUDO_USER (hp- my regular non privileged user that initiatiated sudo mode) instead of $USER (root). Sudo is needed for writing `.service` files to `/usr/` and for start, stop operations with dbus.
That's a good thought. `sudo` is needed for writing to `/usr/`. The service being set up does not have root access. The value of `User=` is $SUDO_USER (hp- my regular non privileged user who initiatiated sudo) instead of $USER (root).
I think it's more about ease of use and developer experience. I agree that in the current state servicer is a proxy to systemd, anything you can do here you can do on systemd. Later down the line I will try to support process managers on Mac and Windows.
I'm happy see this question "Why not use systemd" finally being asked. Apparently the people on NPM (2 million weekly downloads for pm2) ~~disagree~~ don't care. `pm2 start` just works, not everybody is a system admin. There are a bunch of threads around asking for a pm2 for Rust or golang. This tool tries to address this segment.
You can be a linux veteran still benefit with some commands like `ser status` which will only show the services you created, not the wall of text shown by `systemctl list-units`. CPU and Ram usage is thrown in as a bonus so you don't need to run a separate command. It's a neat trick that uses no database. The services end with `.ser.service`, this way we only see the units that servicer created. Run `ser which` and you'll get the unit and service file destination.
That's interesting! I wasn't aware of this command when I started working on servicer. Anyway, there are a couple of utilities like `ser status` and `ser which` which you might find useful.
Thanks for the heads up, I shall update the landing page. The tool tries to detect the interpreter (currently just node and python), but you can provide a custom one with `--interpreter deno`.
> It was my experience to care more about distance, speed, interval, and MTU on actual hardware than protocol confirmation to a PC.
That's exactly my concern, coupled with a (perceived) small pool of Bluetooth developers. Do you think there's a market for a Postman style commercial cloud product for team collaboration?