Understanding Data Types for Rinf Signals (e.g., primitives, DateTime, custom types)

[erflaber]

I have a few questions about the types of data that can be sent within the message part of a signal:

• Can I send anything beyond standard Rust primitive types (u64, i32, f32, String, Vec, etc.), as fields within my signal struct? Such as:
  • Complex Standard Library Types: What about more complex types from the standard library or common crates, such as std::time::SystemTime or chrono::DateTime? If so, would I need to ensure they are serializable, perhaps by converting them to a string or a Unix timestamp, or by using Serde helper attributes (e.g., #[serde(with = "...")])?
  • Custom Data Types: Can I define any custom struct or enum as long as it derives Serialize/Deserialize? Are there any limitations on the complexity or nesting of these custom types (beyond what's covered by SignalPiece for nesting within signals)?

I am trying to understand if I am correct to assume the following governing principle: "If it can be serialized/deserialized by Serde, it can be sent as (or within) the message part of a Rinf signal."

PS: Sorry if the it is an obvious answer

[temeddix]

• Rinf uses Bincode serialization under the hood. Rinf currently supports most of the standard types that Bincode does:
  • Signed Integers: i8, i16, i32, i64, i128
  • Unsigned Integers: u8, u16, u32, u64, u128
  • Floating-Point Numbers: f32, f64
  • Texts: char, String, &str
  • Boolean: bool
  • Sequences: [T; N], Vec<T>, HashSet<T>, BTreeSet<T>
  • Maps: HashMap<K, V>, BTreeMap<K, V>
  • Standard Library Types: Option<T>, Box<T>
  • Tuple Types: ()..(T1, T2, T3, T4)
  • C-Style Enums
  • Enums with Inner Data
• Unfortunately, the current status of Rinf does not allow using things like #[serde(with = "...")]). It would be nice to have such a feature, but because rinf gen analyzes Rust code statically (by reading type annotations), it cannot infer the type behind #[serde(with = "...")])
• You can nest anything that is SignalPiece inside a RustSignal or DartSignal. Also, Serialize and Deserialize will also have their own nesting rules. If there are no compile-time errors and the app builds successfully, you are safe.

Thank you for your participation :)

[temeddix]

To represent time data, I strongly recommend using integer-based timestamps.

[erflaber]

Amazing response, thank you for the detailed explanation.

[brongan]

Can you have Sequence<T> where T implements SignalPiece?

[temeddix]

Yeah, of course. You can use Vec, [T;N], HashSet, BTreeSet.

[temeddix]

I've created new issues related to this topic:

• #[serde(with = "...")]) and its friends should be banned #580
• Possible field types should be introduced in the docs #582

[temeddix]

Now this info is available in the docs

• https://rinf.cunarist.com/field-types/

[willbicks]

It looks like Bincode 2.x introduces a lot more serializable / de-serializable types: bincode-org/bincode#411, but so far rinf has not updated (declined #553).

Some of these new types would be very useful for my project, is there a fundamental incompatability with Bincode 2.x or is the plan to update in the future?

[temeddix]

There are currently two reasons Bincode 2 is not being used:

• serde-reflection doesn't support Bincode 2
• Bincode 2 does not use Serde, and requires significant changes to people who are using Rinf version 8

If we can resolve these issues we might be able to discuss Bincode 2, but they're not easy problems to resolve. I'll say Bincode 2 will not be used by Rinf in the near future.

Thank you for your participation :)