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.

What happenend?

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.

Focus shift

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 icalendar. 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:

imag-bookmark

imag-counter

imag-diary

imag-mail

libimagbookmark

libimagcounter

libimagdiary

libimagmail

libimagnotification

libimagtodo

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-link

imag-ref

imag-store

imag-tag

imag-view (though a Ruby tool might come up with way better functionality)

libimagentrytag

libimagentryview

And the related libraries will be kept as well:

libimagerror

libimagref

libimagrt

libimagstore

libimagstorestdhook

libimagutil

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:

imag-notes

libimagnotes

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:

libimagentryedit

libimagentryfilter

libimagentrylink

libimagentrylist

libimagentrymarkdown

libimagtimeui

libimaginteraction

imag.rb

And we will introduce one new crate: imag.rb . 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, libimagerror , libimagutil , …), but I guess it is a good idea to have libimagtag , libimaglink and the functionality of the other core-libraries in there as well.

How long?

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!