Provide a way to use std::io::{Read,Write} and gio::{Input,Output}Stream interchangeably

[fkrull]

When you have a std::io::Read, it should be possible to use it with gio-based APIs that require a gio::InputStream. Conversely, when all you have is a gio::InputStream, it should be possible to use it with APIs using std::io::Read. The same goes std::io::Write and gio::OutputStream.

When mixing APIs using the Rust types and the gio types, interaction between streams gets hairy. Writing a wrapper for gio::{Input,Output}Stream that implements Read or Write is straightforward enough, but it's also generally useful so IMO it should be included here. However, if all you have is an std::io::Read, the only way I've found to get that to an API that takes a gio::InputStream is to dump the entire stream into a temporary file and re-open that with gio. I think it should be possible to write a gobject subclass of GInputStream -- either in unsafe Rust or in C -- that simply wraps a std::io::Read. This class would then have to be exposed back to Rust in some form.

So in short, things I'd love to see:

• a wrapper for gio::InputStream that implements std::io::Read
• a wrapper for gio::OutputStream that implements std::io::Write
• a subclass of GInputStream that wraps a std::io::Read and can be passed to wrapped APIs
• a subclass of GOutputStream that wraps a std::io::Write and can be passed to wrapped APIs

[sdroege]

For the first two, you could add an impl for Read/Write directly on GInputStream/GOutputStream. Do you want to provide a PR for that?

The other two are a bit more involved as the subclassing story in Rust is not great yet. You can either do it with a bit of unsafe code doing basically the same as one would do in C (which is probably preferred for this case here), or around https://github.com/gtk-rs/gobject-subclass for a generic solution.

[fkrull]

Well, I did say it should be easy, so I'll take a stab at the trait impls later.

As for the other part, I'm not very familiar with either gobject for unsafe Rust. I kinda want to give it a try, buuuuut we'll see.

[sdroege]

Well, I did say it should be easy, so I'll take a stab at the trait impls later.

Feel free to ask for help here if you get stuck somewhere :)

As for the other part, I'm not very familiar with either gobject for unsafe Rust. I kinda want to give it a try, buuuuut we'll see.

Understandable, it's not exactly trivial. If you want to read up on things a bit, see my blog post here: https://coaxion.net/blog/2017/09/exporting-a-gobject-c-api-from-rust-code-and-using-it-from-c-python-javascript-and-others/

And as above, if you want to try and learn, feel free to ask here. I'd be happy to help.

[fkrull]

@sdroege

You can either do it with a bit of unsafe code doing basically the same as one would do in C (which is probably preferred for this case here)

Why do you say that approach is preferred? As far as I can tell, gobject-subclass should support the necessary features, so what would be gained from duplicating (part of) that functionality?

[sdroege]

Why do you say that approach is preferred? As far as I can tell, gobject-subclass should support the necessary features, so what would be gained from duplicating (part of) that functionality?

It doesn't require us to publish a gio-subclass crate for the time being and it's going to be less work (because you would also have to do the GInputStream, GOutputStream bindings in a generic way... while for just this you don't have to worry about genericity).

[sdroege]

@fkrull What's the status here?

I think at this point it would be best to implement subclassing bindings for InputStream and OutputStream, which should be rather easy to do. And then we could have some convenience implementation around that and the Read / Write and Seek traits.

[fkrull]

The status is I haven't done anything on it, sorry. :) I don't need it currently, I probably won't get around to working on this.

[sdroege]

No worries, just checking in case someone else is interested in looking into this :)

[sdroege]

Part of it is here #238

I'll add Read/Write wrappers in a bit

[sdroege]

Those are there too now, only some additional features have to be added.