Proposal: Add `notify` command about timetrace HOT 14 OPEN

@FelixTheodor what do you think of adding also a notification if no tracking is happening?

So we would have a flag or something to also notify after a period of nothing been tracked. I am saying this cause I often forgot to START to track something rather than stoping it.

So we could have 3 ways:

• Notify asking if you are still working
• Notify asking if you are still doing nothing
• Notify both.

I am not sure if this should be implemented inside the binary or a third party/plugin that could also have systray for visual information as well.
But initially, having a simple notify can help =]

What do you think?

from timetrace.

However, I'm curios about your reasoning - #41 seems to change a lot of things under the hood for already existing commands, so I can see why it works better as an extension.
But the notify command would just add functionality "outside" of the existing code. Is it because of the dependency to another library?

In general, I'm not against including the notification feature in the timetrace binary. The idea more was that if there's an easy way to provide extensions, all functionality that goes beyond the stateless, fire-and-forget timetrace command could be provided as such an extension. But the notify command indeed is a feature relevant for a majority of users, so whether it should be directly included in the binary is rather a matter of taste.

from timetrace.

BTW, kubectl plugins could be an interesting take as well: https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/

from timetrace.

Here the POC https://github.com/aligator/goplug
Currently you can provide commands the Plugins can call and also send events, the plugins can listen to.

To use goplug you basically have to create a struct which inherits goplug.Plugin and add Methods which just use RegisterCommand or Send to provide custom commands or events.

Then the plugin just has to create an instance of this struct and call these methods.
It's very basic for now, but my concept should be clear.

from timetrace.

@sfrique I do like the idea! But I think it would then probably require a lot more work, especially if we want a systray and probably automatic start on start-up (I guess, otherwise the feature would not make that much sense if you still need to remember to start the reminder^^)?
And the extension would need to run in background all the time. At the current state, the notify command is still running completely in foreground and it's just hidden by the &. I will first focus on getting this simple notify to work via Plug-Ins, but in the future it could be a fun side-project to build a full notification application for timetrace :)

from timetrace.

I really like the idea! Didn't have the time to view the implementation yet, but it sounds pretty good.

There are at least some requested features that make sense but shouldn't go into the timetrace binary directly, for example #41. This is why I'm planning to support extensions for timetrace (though I'm not yet sure which mechanism I'm going to choose for this). Maybe the notify feature would be a candidate for such an extension as well?

from timetrace.

@aligator Any updates on the extensions architecture?

from timetrace.

Glad that you like the idea!

This feature can of course be a candidate for an extension, so if you think that's the most clear way to do it we should go for it :)
However, I'm curios about your reasoning - #41 seems to change a lot of things under the hood for already existing commands, so I can see why it works better as an extension.
But the notify command would just add functionality "outside" of the existing code. Is it because of the dependency to another library?

from timetrace.

Thanks for the explanation!

Since I'm curious how extensions would look like on a technical level, I won't mind to provide this feature as one. I agree that its a matter of taste. On the long run, one could even take a look at download statistics of the extension and decide based on that if something is popular or important enough to go into the main binary :)

from timetrace.

@aligator Any updates on the extensions architecture?

As I have currently broken internet, I did not do much.
What I did so far is using timetrace as lib and implement the filesystem interface by a fake-clockify filesystem. Some parts I had to alter in timetrace to make this work.

But this approach has the downside, that you have to create a new timetrace binary for each combination of plugins. I don't think thats feasible when we want to support several plugins. (BTW. Caddy did it this way but there is also a very complex build system around it.)

Another possibility is to create a small API (+maybe a lib to call it easily), create an extra binary for each plugin which calls that API and then let timetrace automatically start all binaries from the plugin folder. These would have to communicate with timetrace over the api.
As timetrace is only a short running program, I am not sure if this would start fast enough to work nice as there has to be started a webserver somehow (or similar). Is there any easy to use IPC (Inter Process Communication) for Go out there?

Also possible would be to call these binaries and pass information by piping it to the stdin of it and getting information by reading the stdout of it.

The latter seems to be the easiest way. But I haven't tried something like this yet. The commands could just be sent end received using json strings.
Maybe I do some experiments in this area soon :-)

What do other Go projects use? Is there maybe already a lib for Go IPC?

from timetrace.

Just found https://github.com/hashicorp/go-plugin
Seems to be stable and widely used. But I am not sure how good it works with a one-shot comand such as timetrace.

The idea with stdin / stdout will only work with plugins which live only as long as the timetrace comand runs. So in case of the notification timer it's maybe not the best way.
Edit: Just looked over your initial implementation of the notification. It could work with the stdin / stdout approach, if we allow plugins to prevent timetrace from stopping execution...

from timetrace.

I am playing around now with creating a POC plugin framework based on the stdin / stdout.

from timetrace.

@dominikbraun What do you think about #104?

from timetrace.

@aligator Thanks for your effort, I'm going to take a look at it.

from timetrace.