What is the future for rdial
?¶
Where things stand now:
$ time ./rdial.py --no-cache report --stats
65726 events in query
Duration of events 780 days, 14:04:22
First entry started at 2011-12-15 14:02:13
Last entry started at 2019-05-27 19:55:13.803240
Events exist on 2659 dates
Task “rdial” started 2019-05-27T19:55:13.803240Z
./rdial.py --no-cache report --stats 0.55s user 0.05s system 92% cpu 0.649 total
I’m clearly an extensive rdial
user, and my inbox tells me that there
are fair number of other — hopefully happy — users too. There are no plans
to stop working on it, but there are some thoughts about where it could go.
Data storage¶
The output above is fairly representative of the speed of rdial for me 1. All non-interactive commands run in well under three quarters of a second, and with the cache enabled the commands run within half a second. Performance should be better, but I find it to be within acceptable bounds.
One of the original goals of rdial
was “easily
accessible data, in a format that can be processed simply”. The CSV-backed
storage is easy to work with, and performance is acceptable. However, I’m more
than a little tempted to replace it with a sqlite-backed solution because:
sqlite
is clearly a battle tested solution.Tests show performance improvements, although the large bottlenecks are in marshalling.
The command line interface, sqlite, can export in various formats (including CSV).
It would remove the need for most of the chicanery around loading and saving of data, probably significantly improving the stability.
A small number of the reports that I generate with
rdial
are actually performed by importing the data in to asqlite
in-memory database via its CSV support, which proves the suitability already.
- Likelihood
✪✪✪✪○
- Effort
✪✪○○○
Language¶
I’m moderately happy with Python as the implementation language, although have considered switching a couple of times to improve command response times.
Over the years I’ve re-implemented rdial
to various extents when playing
with new languages:
Language |
Pros |
Cons |
---|---|---|
|
|
|
|
|
|
|
|
Note
While clearly not new languages, both Genie and C
have been considered
too. Genie
would be a good fit, but it is not clear what future it
has. C
would basically be either a huge amount of work or a simple
wrapper around existing libraries 2, neither of which I find compelling.
I’ve also considered the git approach, with a fast top-level wrapper invoking external subcommands that could be in different languages. This way we can have super fast commands where they’re really needed(rdial {start,stop,switch}), and choose a feature appropriate language for other commands(rdial report for instance). While attractive, it would make packaging far more annoying.
- Likelihood
✪✪○○○
- Effort
✪✪✪✪✪
Interfaces¶
A couple of users have expressed an interest in alternative interfaces, but I’m not very enthusiastic about working on them myself. I understand the desire, but don’t feel it is worth the effort. Added to that, if I’m not going to use them myself, I’m probably not the best person to produce them.
That said, I do use rdial
outside of the command line, but entirely by
wrapping the command line interface. This feels like a reasonable solution,
but would benefit from a faster implementation and a guaranteed output
format.
So, my intention would be:
Adding full documentation for my awesomewm integration.
Open sourcing the Android Wear swipe integrations for my watch.
A faster implementation.
Guaranteed stable output format.
- Likelihood
✪✪✪○○
- Effort
✪✪✪○○
Footnotes