Add tedge api only

[TheNeikos]

Proposed changes

This is an extracted part of #948 which this PR would subsume. The idea being that having a smaller change on which we can all agree will make it easier to iterate on.

Types of changes

• Adds a new tedge_api crate
• Adds a goals.md file to it with an explanation for its goals and implementation

Further comments

As for #948 please leave your comments/ideas inline with the PR to make it easier to discuss!

[makr11st]

Looking at the proposal it seems like the idea here is to basically create an actor model for the core API, if that is the case why not use an out of the box solution and just adjust messages and tasks accordingly. With an actor design we focus more on the state rather than how do we pass messages. It looks like maybe actix would be a good candidate, however, not the only option (and maybe a little bit large to take) we could look at alternatives.

[TheNeikos]

@makr11st that is indeed a good question, my understanding is that actor libraries in Rust have so far been mostly for web servers, which is too broad a scope for thin-edge, and being completely compile-time which goes against the idea of having a modular-by-configuration feature.

I only know actix, and found it not to fit as while it does also represent an actor model, its implementation is different enough that I don't see it as useful for us. I'm happy to be wrong though, if you know how it could fit!

[matthiasbeyer]

@makr11st I also thought a bit about that, and the main difference I saw, which is IMO the reason why we would rather implement our own message passing system here as we did: Actor systems are "without state by default, optional you can have state", so they make it easy to not have state in the actor implementation, but give you the option to have state if you really need it. Whereas our system would be exactly the other way round, as far as I understand it: What we call "plugin" right now almost always has state, so it should be easy to have. If it is not needed, then there is no extra cost in just not using state.

---

Only my 2ct, as I have also only experience with actix (actix-web) and not much more :laughing:

[makr11st]

By saying actix I do not mean the actix-web as it is a particular implementation of a web server which uses basic actix actor design for message passing and requests handling.

To my understanding the proposal for the core you made is exactly this, a message passing and request handling engine and therefore I see no reason to reinvent this with custom implementation especially I'm pretty certain that even though in the current state 'we only pass some message around' in the near future we will have to work with state and 'plugin' context, which by using actix we get for free out of the box. Additional advantage you get with using it is that you can load/unload actors/plugins at a runtime due to dynamic nature of the interface.

@makr11st I also thought a bit about that, and the main difference I saw, which is IMO the reason why we would rather implement our own message passing system here as we did: Actor systems are "without state by default, optional you can have state", so they make it easy to not have state in the actor implementation, but give you the option to have state if you really need it. Whereas our system would be exactly the other way round, as far as I understand it: What we call "plugin" right now almost always has state, so it should be easy to have. If it is not needed, then there is no extra cost in just not using state.

I'm a little bit confused by this observation, state/context is a default feature in actix and even if it wouldn't be I see no reason why not just enable it.

[matthiasbeyer]

By saying actix I do not mean the actix-web

Yeah :laughing: that was just what I meant I have some experience with (as in: I have experience with actix-web, not the actix crate directly). Sorry if my wording was not clear enough on that part!

I'm a little bit confused by this observation, state/context is a default feature in actix

Ah, I messed something up in my head in this regard, sorry for the confusion!

[didier-wenzek]

As proposed by @makr11st we must evaluate https://lib.rs/crates/actix in this context.

[TheNeikos]

@makr11st

By saying actix I do not mean the actix-web as it is a particular implementation of a web server which uses basic actix actor design for message passing and requests handling.

Yes, and since it also uses the message passing paradigm it looks fairly similar to what we've proposed, and I find that okay. What would be the advantages of using such a crate? A big disadvantage I see is that we'd be bound to their implementation of the paradigm instead of a specialized one that might serve us better.

However, I do believe that some parts of it could be used by us. It's Handler and Addr types give a great inspiration on how one could refine the tedge_api so as to implement what @didier-wenzek had thought of, which is to have typed 'plugins'. I'll do a small POC to see if it works.

I think a blocking issue I see with actix is that you cannot create circular dependencies between actors. Since each actor's address is only known once it is created, you can't create two actors at the same time that require each others address. (This might be the case between a mapper and a 'systemd' plugin, where one might tell the other about changes)

[TheNeikos]

I'll close this until a clear path for the next steps exists.