mioco::Evented cannot be implemented externally

[jeremyjh]

mioco::Evented is public but is constrained to types which are prv::EventedPrv, which is private. How can we have event sources defined in external crates? I began work on an event source for nanomsg which should be a separate crate from mioco, but can't see how to do that without making EventedPrv public.

[dpc]

When refactoring to support lack of wrap, I have given up the idea of user implemented Evented types, and used prv::EventedPrv to hide some internals from the user. The reasoning is: since the mio itself has a fixed set of supported IO, all user IO will have to build on top of that IO anyway, except maybe primitives like timers and locks, which mioco should provide.

However I have no strong opinions about it, and could remove this constrain if there's a good reason. Can you elaborate how are the types you want to add supposed to work? Is there any reason why can't they be just structs wrapping exisiting types?

As a workaround, you could make prv::EventedPrv public locally, until we figure what to do about it.

[jeremyjh]

Hi, I can create my own Mio types as they exist today - it expressly supports this. Nanomsg is a C library which provides message framing and a variety of higher level messaging pattern implementations for a number of languages and platforms. Nanomsg-Rs is the rust wrapper. I can get raw descriptors from nanomsg and make a mio evented type already. But I would also need to be able to create mioco instances as well. If mio is successful this will come up a lot - we'll see mio versions of database libraries and other higher level constructs that may be directly useful in mioco - and we would want to wrap them and not rewrite them using the mioco primitives.

On Thursday, January 21, 2016, Dawid Ciężarkiewicz notifications@github.com wrote:

When refactoring to support lack of wrap, I have given up the idea of user implemented Evented types, and used prv::EventedPrv to hide some internals from the user. The reasoning is: since the mio itself has a fixed set of supported IO, all user IO will have to build on top of that IO anyway, except maybe primitives like timers and locks, which mioco should provide.

However I have no strong opinions about it, and could remove this constrain if there's a good reason. Can you elaborate how are the types you want to add supposed to work? Is there any reason why can't they be just structs wrapping exisiting types?

As a workaround, you could make prv::EventedPrv public locally, until we figure what to do about it.

— Reply to this email directly or view it on GitHub https://github.com/dpc/mioco/issues/78#issuecomment-173478296.

[Drakulix]

@dpc maybe implement a new type that can wrap any mio type and provides a function to pass a closure that may modify it.

Something like:

impl<T: Evented> for RawMioType<T>
{
    fn new(mio_type: T) -> Self

Which could then be used like this:

let mio_type = (custom implemented evented type);
let mioco_type = RawMioType::new(mio_type);
mioco_type.use(|&mut mio_type| { //this call wraps before executing th closure and unwraps after it

});

And also make RawMioType implement Read if the wrapped mio-type did and Write as well.

impl<T: Read + Evented> Read for RawMioType<T> {
    ...
}

[dpc]

So it all comes down to: mio allows people to create types impelenting mio::Evented, and it would be nice if these were usable in mioco? OK.

Mioco already has some form of a impl<T : mio:: Evented> Evented for T {... }. Something like @Drakulix solution should be doable.

I need to spend some time to understand this, and then address it. If anyone has a spare time and would like to give it a try, please go ahead.

[dpc]

@jeremyjh , @Drakulix , Could you take a look. I've modeled mioco::Evented after mio::Evented, so any struct can implement it now, passing the calls to the underlying mioco type. Would that be good enough?

[Drakulix]

Could you provide a small example how to use it? How shall one implement Evented, if everything is #[doc(hidden)]? Is it an unstable api?

I was hoping for something like impl<E: mio_orig::Evented> Evented for E. Is that impossible?

[dpc]

I've pushed a more elaborate version with explicit MioAdapter. So basically if you have anything implementing mio::Evented you can feed it to MioAdapter::new.

I've copied doc hidden method from here. http://rustdoc.s3-website-us-east-1.amazonaws.com/mio/master/src/mio/io.rs.html#8 .

Does this all make sense? :D

[Drakulix]

Now that looks good! I think you may close this now

[jeremyjh]

Looks good!