Displays MythTV status (free space and upcoming recordings)
Note: Binary files aren't shown on the web site. To see all files, please download the extension zipfile.
Version | Status |
---|---|
17 | Active |
16 | Active |
15 | Active |
14 | Active |
13 | Active |
12 | Active |
11 | Active |
10 | Active |
9 | Active |
8 | Active |
7 | Active |
6 | Active |
5 | Active |
4 | Active |
3 | Rejected |
2 | Inactive |
1 | Rejected |
A bash script? Really? Please rewrite it in JS with Soup.
What, you're rejecting it on *stylistic* grounds? If my JS skills were up to writing the thing wholly in JS in the first place, I would have. Anyway, it seems that Soup in an HTTP protocol API HTTP, and while it's possible to get MythTV's status via a pseudo HTTP interface at the moment, it's likely that's becoming deprecated, so I wanted to hide the actual fetching impl. from the extension proper (& in my local set up, the data comes from a local SQL server, e.g.).
No, I'm rejecting it because it's unreviewable, in its current form. It uses pseudo-obscure bash features. It forks off multiple processes, some of which in the background. All this, as I read it, to fetch http://$mythhost:6544/xml using a standard HTTP GET. (and if this is not correct, it is another point in favour of not approving it, as I cannot approve code I don't understand)
Yes, that is the current default & fall-back mechanism for fetching the data. However, it's not what I use locally and I expect it to change to something more obscure, neither of which I have any plans to try implementing in JavaScript. I've found during the process of this exercise that the JavaScript bindings for most APIs to have painfully sparse documentation, and now I've gotten it to the stage where it seems to be pretty rock-solid, I don't really want to go fiddling for the sake of it. If you feel it could do with more comments, or is doing something fundamentally unsound, then I'd be happy to rework it. I don't mind writing a small essay explaining the bash stuff if need be (e.g., I started with temporary files, but wanted to reduce the disc churn over long periods so changed it to pipes, and I needed to fork off the requests (à la Soup) instead of sync-command them as I couldn't guarantee how long they might take for a given set-up).