Dominik Braun

@FelixTheodor But don't build something too serious. @aligator found yet another way to solve the plugin communication, but due to the (over-?) complexity of these approaches we're currently thinking about...

> Hello, with respect to to the disadvantage of approach 1, has a SQL-like implementation been considered? Without necessarily migrating to a database, we could implement something similar by maintaining...

@jwnpoh In theory, no, because we'd store the project _IDs_ in the records, not the project keys. Renaming a project would just mean to remove the key from the index...

> In practice however, I'm not sure how this could be done backwards-compatible so that old records with keys in them still work... 🤔 We could simply treat current project...

> Can I clarify that this disadvantage: > > > In theory, this approach would still result in an O(n) complexity when projects have to be looked up the other...

Even though timetrace is still at v0.10.0, I'd like to maintain backwards-compatibility. So there are three options to switch to UTC: * Leave everything as it is and convert record...

@Kevin-Mok Feel free to work on it when it suits you 😄

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

@aligator Any updates on the extensions architecture?

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