What's coming up in imag (22)
This is the 22th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.
imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.
My masters courses are hard (time-wise). I didn't manage to do anything at all in the imag codebase. I hate it. I really want to get imag in a usable shape. So here's what I want to do to make this huge task a bit more achieveable.
I wrote about integrations before. I want to shift the focus of my work on imag to develop a Ruby gem from the imag functionality. This will be the next release. I will write either one or several gems with the imag libraries as backend, so one can write integrations in Ruby. I will do this because I think that the Ruby ecosystem fits the problem pretty well.
So what is the problem?
The problem is the following. We have a working imag store. We have working libraries on top of that “database layer” – namingly tags, refs (though they could use some polishing and features) and most importantly links (both external and internal).
What we do not have is the whole
$tool -> database stuff.
So we cannot put mails into the store, because we need to parse mails.
We cannot put calendar data files into the store, because we need to parse
We cannot put contacts into the store because we need to parse vcard.
And so on and so forth.
But the Ruby ecosystem has libraries for all these things.
So the obvious solution is to write a Ruby integration. We can then write the simple data-format-transformation tools in Ruby and we will be faster implementing it. We do not need the guarantees Rust gives us here – they would be nice, but they are not necessary!
Later, for querying the store, we can write the simple stuff in Ruby as well and the more complex stuff – or the performance-critical parts – in Rust.
How to do the shift?
I guess I will branch-off a major branch for the shift and remove some of the functionality which is already in the repository, namingly:
These tools implement functionality which would be way better be implemented in Ruby.
Clearly, some functionality can be kept. We can keep some of the more basic commands:
- imag-view (though a Ruby tool might come up with way better functionality)
And the related libraries will be kept as well:
I'm not sure about
imag-notes though. A Ruby tool might have better
functionality for this, though
imag-notes works for me pretty well so far,
so we might keep it, and its library:
The other libraries... I'm not sure. Maybe some of the tools listed above need them (really... I haven't looked at the codebase for a long time now cry). So maybe we must keep them, maybe we can remove them:
And we will introduce one new crate:
This will be a ruby crate – so we will use
ruru to build a Ruby gem out of the
functionality implemented in the core crates.
Clearly, the first step would be to put the
libimagstore interface into this
crate (plus its dependencies,
libimagutil, ...), but I guess
it is a good idea to have
libimaglink and the functionality of
the other core-libraries in there as well.
Your question might be: How long will this take? Well. Yes.
I really don't know. As said countless times: Masters degree is engaging. I hope I can get some things done after my exams (which end mid-february). until then – I don't think I have time to do much things.
Help is appreciated, though!