Refactor to be more Rust-ic about dbus-rs HOT 22 CLOSED

Not sure what to say. Sounds interesting, but I don't quite follow so I'm not sure whether this is a good idea or not. Maybe it's easier to get down to coding instead of discussing.

• is a "dbus xml file" same as introspection output?
• what methods would your suggested Interface have?

from dbus-rs.

@diwic Yes, I meant introspection output.
It's kinda hard to answer the second question, since I realized what I wanted to do initially is not possible . My idea was a separation of the inner message types and the rust types ie impl ReadOnly<String> for MyProperty, but then the aforementioned Property enum would also need a type parameter, which is not what I wanted. I mean it could just be fn property() -> MessageType, but that's where the separation part comes through, I think this problem could be solved by implementing serialize, which would allow this to be "more Rust-ic" ex. fn get_property() -> Encodable + Decodable (both because the client would have to decode, while the library would have to encode if the Interface is a server), so that any type that has Encodable + Decodable implemented could be passed. The same thing is valid for methods, their return values and arguments. I was also thinking that the Rust-ic way of handling signals would be through channels. What do you think?

from dbus-rs.

Rust is currently missing abstract return types, so you can't return Encodable + Decodable from a function, but maybe you mean Box<Encodable + Decodable> or so.

If I understand you correctly, you wan't to avoid exposing MessageItem and instead use native rust types that can serialize into MessageItems instead, wherever possible? If so, I think you should start by making a good implementation of Encodable and Decodable for MessageItem (i e solve issue #10). I'm all for having that, and once we do have that, we can see how we can extend that functionality to cover for properties and other things as well. Sounds like a plan?

from dbus-rs.

@diwic Sure! (BTW, won't <T: Encodable + Decodable> -> T work?)

from dbus-rs.

(BTW, won't <T: Encodable + Decodable> -> T work?)

I remember asking the same thing some time ago, and I'm not the right person to explain the details, but the tl;dr version is that that will not do what you would usually want.

from dbus-rs.

@diwic What if instead of implementing serialize we create our own trait (Messageable), because serialize is too sophisticated for what we need to do, and this is gonna be relatively easy.

from dbus-rs.

@boghison There is already the FromMessageItem and Into<MessageItem> traits, how do these differ from what you're planning to achieve?

from dbus-rs.

@diwic Wait, you're right, then why do we need serialize?

from dbus-rs.

I'm not sure if we need serialize for what you want to do, because I'm still not sure what you want to do.

I haven't investigated serialize myself much, but I assume it would be helpful if you want to do a direct conversion from a struct to a Vec and back again, as you can derive Encodable and Decodable on the struct itself.

from dbus-rs.

@diwic Struct to Vec? What's the point of that? Or do you mean a DBus array, but that's not very idiomatic IMHO

from dbus-rs.

It would enable us to do something like this:

 #[derive(Rustc_encodable)]
 struct SomeInfo(i32, String, u64)

 /* ...  */
 msg.encode_and_append_items(&someInfo);

from dbus-rs.

@diwic Is there actually an use case for that?

from dbus-rs.

Since it has been requested in issue #10, I'm inclined to say yes.

from dbus-rs.

@boghison I don't know if you're still following this thread, but if you do, you might be interested in my new Arg module which is a replacement for MessageItem.

from dbus-rs.

@diwic Oh! How is it different? (Sorry, it's literally been half a year :D)

from dbus-rs.

@boghison it's monomorphic/generic and can append/get arguments directly into D-Bus without turning them into MessageItems. Link to documentation

from dbus-rs.

@diwic any chance we could have an example of its use (either in the docs or in the sample code)? If you're busy, I may take a stab once I convert my code using MessageItem, and understand how it works better...

from dbus-rs.

@agrover It's already there:

In client.rs, you will now find let arr: Array<&str, _> = r.get1().unwrap(); - these strings are now pointing directly into somewhere inside the message, no extra allocation,

and in server.rs, it's now .outarg::<&str,_>("reply") - notice how you don't need to know about type signatures anymore, you can just have them autogenerated for you using a generic method.

That said, not everything inside my dbus library is converted to use these methods yet.

from dbus-rs.

If you want to see something slightly more complicated, right now the most complete is probably the msgarg test case which tests sending and receiving different types of arguments. Indeed there could have been more examples of this in the docs.

from dbus-rs.

On another note, what you're saying about generating traits from introspection data is starting to make some sense to me. If we take a simple example, the org.freedesktop.DBus.Introspectable interface could be seen as something like:

pub trait OrgFreedesktopDBusIntrospectable {
    fn introspect() -> String
}

And then on the client side, you would somehow be able to get something that implements this:

let i = ClientFactory::get::<OrgFreedesktopDBusIntrospectable>(&connection, destination, path);
println("{}", i.introspect());

...and when calling introspect, that would then, under the hood, create a message, send it, block while waiting for reply, get the string out of the argument, and finally return it. (And deal with errors.)

And then we need something similar on the server side, but there you're the trait implementor rather than the caller. And this needs to integrate with Tree somehow.

All of this seems like a substantial piece of work, so although interesting, it's nothing I plan to do in the near future.

from dbus-rs.

Btw, I just discovered there is a dbus-macros crate that takes an interesting approach to this. It lets you manually specify methods like fn introspect() -> String inside a macro, and that macro creates the client or server implementation for you.

That idea seems interesting.

from dbus-rs.

I'm going to close this on the basis of

• We now have a dbus code generator which does some of the above
• No activity for almost a year, I think this issue is obsolete or needs to be rethought in a new bug.

Feel free to reopen if you disagree.

from dbus-rs.