Age | Commit message (Collapse) | Author |
|
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
feature/add_tedge_api_only
This changes the API so that the core implementation must no longer use
channels for plugin communication dispatch, but can use direct function
calls.
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
|
|
So a core implementation can easily access it.
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
|
|
Previously it also printed the 'reply_sender' which was very noisy and
provides no added information to users.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
Reviewed-by: Matthias Beyer <matthias.beyer@ifm.com>
|
|
The plugin "main" should implement the main usecase of the plugin. This
is where plugin authors should do their work.
Of course, having a default implementation makes implementing a Plugin
that only handles messages as easy as it can get: An author just has to
implement an seemingly empty `Plugin` trait for their type, plus the
`Handle<>` implementations for message handling.
If they want to do extra things, overwriting the functions from `Plugin`
is the way to go.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
Reviewed-by: Matthias Beyer <matthias.beyer@ifm.com>
|
|
This patch adds default bodies for the `Plugin` trait methods, as some
plugins don't want to do anything in these functions, so they would
implement them with simply returning `Ok(())` anyways, which we can do
here equally good.
This results in less brain-load on the Plugin authors side as well.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
Reviewed-by: Matthias Beyer <matthias.beyer@ifm.com>
|
|
MPSC are a heavy form of indirection that is potentially not needed.
This patch removes them and instead opts to use a Fn Generator of
futures that correspond to the model of communication One Question ->
One Reponse.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
Reviewed-by: Matthias Beyer <matthias.beyer@ifm.com>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
While HashMaps represent the idea of a 'struct' better, it has some
drawbacks:
- iteration order is random
- constructing it requires random state (minor)
A vector here saves the same purpose but without the above drawbacks.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Wrapping another config is very useful for narrowing down configs. This
patch adds this possibility for authors.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
This patch allows the retrieval of a potential configuration for a
plugin kind.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
With this object we can interact with the configuration of a plugin kind
programatically. This has its uses for example for printing
documentation.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
This patch adds the ability to send any kind of messages to plugins that
declare handling `AnyMessage` + `AnyMessages`.
It does it with these changes:
- Remove the `Message::Reply` associated type
- This allows `Message` to be used as a trait object
- Add the `MessageType` which allows to identify messages
- This permits `AnyMessage` to be received by plugins
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
Fixes: 50097a89 ("Add send_with_timeout")
Fixes: 449d2f3b ("Add try_send method")
Fixes: 86530000 ("Rename send to send_and_wait")
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Fixes: 041abc6b7b6b4d2cc9f9cecabeab3ecc501fea6b ("Add doc: PluginBuilder")
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Sending messages with a timeout ensures that if a plugin takes too long
to accept the message this method eventually returns.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
This method is useful for plugins that do not wish to get caught in
potentially await forever if the receiving plugin does not handle the
messages it is sent.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Make it clear that sending messages can potentially block indefinitely
if the target plugin does not handle them.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
'Setup' is not very clear in where it would be called in its lifecycle.
Start makes it clear that this is the starting point of a plugins
lifecycle.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
While having spanning information is very important for good error
messages, the current system is not very well suited for it anyway. This
patch removes the spanned wrapper to simplify current implementations,
with an outlook to a better replacement.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
This patch adds a function to check whether the ReplySender was closed.
This means that the plugin that sent the initial message stopped waiting
for a reply.
This can be useful for building a pipe-through like plugin, that
receives messages that it sends to another plugin and only executes a
side effect for each message.
(cherry picked from commit 8375962db6d448eb1cff1c9c73f3c6a615f3f6ff)
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
This trait simplifies a lot of the message calls in the PluginBuilder.
Advantages: You only declare a list of handled messages _once_. This is
necessary since Rust does not allow 'queries' for types (aka "give me a
tuple of supported types" does not exist), and so the necessary crutch
is to declare them manually.
Disadvantages: You cannot pick at Runtime anymore what messages you
decide to support. This is considered to be a very niche use-case and
might actually be an anti-pattern.
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
This patch updates the docs for the HandleTypes type and adapts all
doc tests to the new interfaces.
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
|
|
This patch updates the docs for the PluginBuilder type and adapts all
doc tests to the new interfaces.
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
|
|
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Previously the 'Address Types' were covariant with their generic type T. This
means that rustc understood `PhantomData<T>` to be 'equivalent' in
subtyping to `T`. This has implications for auto traits like `Send` and
`Sync`, because this means that the `Address Types` only implement those
if `T` does as well! But this is overly restrictive, the 'Address Types'
never contain a `T`! Nor do they ever touch it, hence we are using
`fn(T)` to tell rustc that it should treat it in a contravariant
fashion, meaning that in this case it is not dependent on `T` and always
implements `Send/Sync`.
Additionally, static tests were added to ensure this in the future.
This also removes some unsafe code, which makes this crate once again
free from it! 🎉
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
This patch removes the `Clone` trait bound from the `PluginDirectory`
trait, because we pass the `PluginDirectory` implementing type as a
reference to a `PluginBuilder` when it is used to instantiate a
`Plugin`. The `PluginBuilder` implementation can then pull the required
`Address`es from the instance of `PluginDirectory` and keep them, not
requiring the implementation to keep the whole `PluginDirectory`
object.
This makes the API simpler, and we can remove the `Clone` trait bound
because of this.
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|
|
Signed-off-by: Matthias Beyer <matthias.beyer@ifm.com>
Signed-off-by: Marcel Müller <m.mueller@ifm.com>
|