Nit: if the string is short maybe use a short string like compact_str we use in cu29_runtime if possible?

I am not sure about forcing static here, if you parametrize the type I think the implementor/users of that trait can always use static for it:

pub trait RosMsgAdapter<'a> {
    type Output: Serialize;

    fn namespace() -> &'a str;
    fn type_name() -> &'a str;
    fn convert(&self) -> Self::Output;
}

impl<'a> RosMsgAdapter<'a> for MyMsg {
    type Output = MyRosCompatibleMsg;

    fn namespace() -> &'a str {
        "std_msgs"
    }

    fn type_name() -> &'a str {
        "String"
    }

    fn convert(&self) -> Self::Output {
        MyRosCompatibleMsg { ... }
    }
}

Let me known if it sounds better now.

I was thinking about the convert method ... this is just a not very idiomatic way of a From/Into, you can force the trait with a +

pub trait RosMsgAdapter<'a>: Into<Self::Output> + Sized
where
    Self::Output: Serialize + 'a
{
    fn namespace() -> &'a str;
    fn type_name() -> &'a str {
        ros_type_name!(Self::Output)
    }
}

^ that feels more like the signature I would expect

Actually it tried to do it this way but I failed.
The point is that Into requires self to be moved fn into(self) -> T; and it would force to use clone into the sink implementation.
Is there a way to workaround this issue?

This will be the basic public description on Crates.io, maybe mention that it is part of copper/extra payload for copper.

maybe small_str

can't we just use the standard "Into" facility of Rust here?

if the type_name is almost always the Struct name you can provide it for the user with a small default impl in the trait maybe?

pub trait RosMsgAdapter<'a> {
    type Output: serde::Serialize;

    fn convert(&self) -> Self::Output;

    fn namespace() -> &'a str;

    fn type_name() -> &'a str {
        ros_type_name!(Self::Output)
    }
}

#[macro_export]
macro_rules! ros_type_name {
    ($t:ty) => {{
        std::any::type_name::<$t>()
            .rsplit("::")
            .next()
            .unwrap()
    }};
}

link to the playground with a little test:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=c10055c62bf8aadd4e77e9920d3965a7

note that the user can override this behavior in the implementation

That breaks the "self-contained" nature of the Copper config.

We do an include! of the RON file at compile time to be able to have a 1 file deployment and a path to a no_std deployment too: ie. no filesystem at all.

is it possible, maybe in another PR to provide an embedded version of it: for example a config_str: and the inline version of the json file?

The publisher has to be static here?

Actually, as far as I understand, it only means that the "key expr" is owned. But maybe I'm missing something.

So what I understand is that basically either it is a static string OR you won't be able to deallocate the publisher (Box::leak), so the ZenohRosContext, so the session etc.. ?

I believe you need to forward those lifetimes to the Context.

'static is really what it means, it will be never ever be deallocated.

I believe you need to forward those lifetimes to the Context.

I also tried this but I can't figure out to forward those lifetimes beyond code generated from the RON file.
But I'm not sure it is a big deal.
This lifetime is related to the keyexpr stored inside the publisher and according the documentation
https://docs.rs/zenoh-keyexpr/latest/zenoh_keyexpr/

KeyExpr works like a Cow, but also stores some additional context internal to Zenoh to optimize routing and network usage.

AFIU this means that using static lifetime implies key expr cannot be borrowed https://github.com/eclipse-zenoh/zenoh/blob/63a6e33fe58eb98485c13dad0924f673baedc060/zenoh/src/api/key_expr.rs#L40
And we don't care about that as we have to compute the key expr.

'static is really what it means, it will be never ever be deallocated.

Not necessarily. My understanding is it can be hold for as long as needed.

https://doc.rust-lang.org/rust-by-example/scope/lifetime/static_lifetime.html#trait-bound

But maybe I'm missing something...

while correct rust, this 'static feels out of place. Conceptually those types only need to live for the duration of one CopperList ie. one execution cycle.

So what I understand is that basically either it is a static string OR you won't be able to deallocate the publisher (Box::leak), so the ZenohRosContext, so the session etc.. ?

I believe you need to forward those lifetimes to the Context.

'static is really what it means, it will be never ever be deallocated.

I was thinking about the convert method ... this is just a not very idiomatic way of a From/Into, you can force the trait with a +

pub trait RosMsgAdapter<'a>: Into<Self::Output> + Sized
where
    Self::Output: Serialize + 'a
{
    fn namespace() -> &'a str;
    fn type_name() -> &'a str {
        ros_type_name!(Self::Output)
    }
}

^ that feels more like the signature I would expect

How heavy it’s to create a new session per task, instead of having somehow a global ?

That's a good point. At some point, it would be nice to find a way to have a single session and multiple publishers across many tasks.

in a separated project using copper I have instantiated within a global lazy operator

This sounds great. However I'm wondering how to define a single zenoh session config for all the tasks inside the RON file? 🤔
@gbin any thoughts about this?

I think we really need a new kind of "service" task just holding a state / running a daemon thread. I propose to add that as an issue for that and discuss the arch and determinism on the issue. For now let's move forward with this PR with the known limitation then refactor it with the new facility in the framework.

really good idea. Looking forward to it