{"action":"created","issue":{"url":"https://api.github.com/repos/sdroege/gstreamer-rs/issues/78","repository_url":"https://api.github.com/repos/sdroege/gstreamer-rs","labels_url":"https://api.github.com/repos/sdroege/gstreamer-rs/issues/78/labels{/name}","comments_url":"https://api.github.com/repos/sdroege/gstreamer-rs/issues/78/comments","events_url":"https://api.github.com/repos/sdroege/gstreamer-rs/issues/78/events","html_url":"https://github.com/sdroege/gstreamer-rs/pull/78","id":293961032,"number":78,"title":"Query: proposal to solve the deref/deref_mut issue","user":{"login":"fengalin","id":28687262,"avatar_url":"https://avatars0.githubusercontent.com/u/28687262?v=4","gravatar_id":"","url":"https://api.github.com/users/fengalin","html_url":"https://github.com/fengalin","followers_url":"https://api.github.com/users/fengalin/followers","following_url":"https://api.github.com/users/fengalin/following{/other_user}","gists_url":"https://api.github.com/users/fengalin/gists{/gist_id}","starred_url":"https://api.github.com/users/fengalin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fengalin/subscriptions","organizations_url":"https://api.github.com/users/fengalin/orgs","repos_url":"https://api.github.com/users/fengalin/repos","events_url":"https://api.github.com/users/fengalin/events{/privacy}","received_events_url":"https://api.github.com/users/fengalin/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2018-02-02T17:16:02Z","updated_at":"2018-02-05T09:25:31Z","closed_at":null,"author_association":"CONTRIBUTOR","pull_request":{"url":"https://api.github.com/repos/sdroege/gstreamer-rs/pulls/78","html_url":"https://github.com/sdroege/gstreamer-rs/pull/78","diff_url":"https://github.com/sdroege/gstreamer-rs/pull/78.diff","patch_url":"https://github.com/sdroege/gstreamer-rs/pull/78.patch"},"body":"While trying to solve the deref/deref_mut issue on concrete types, I came up with the approach in this commit. The idea is to allow working with concrete implementations directly. Except for pad probes, views are no longer necessary. See unit test and examples.\r\n\r\nIn pad probes, the user gets the query view directly. E.g.:\r\n``` rust\r\n    src_pad.add_probe(PadProbeType::QUERY_UPSTREAM, |_, probe_info| {\r\n        if let Some(PadProbeData::Query(ref mut query_view)) = probe_info.data {\r\n            match query_view {\r\n                &mut QueryView::Duration(ref mut duration) => {\r\n                    duration.set(2 * SECOND);\r\n                },\r\n                _ => (),\r\n            }\r\n        }\r\n        PadProbeReturn::Ok\r\n    });\r\n```\r\n\r\nNote: calling `view` consumes the query, but I don't think this is an issue as the idea is to work on concrete implementations and the user should no longer need to call `view` anyway.\r\n\r\nIf I'm not mistaken, this could apply to `Event`s & `Message`s too."},"comment":{"url":"https://api.github.com/repos/sdroege/gstreamer-rs/issues/comments/363026744","html_url":"https://github.com/sdroege/gstreamer-rs/pull/78#issuecomment-363026744","issue_url":"https://api.github.com/repos/sdroege/gstreamer-rs/issues/78","id":363026744,"user":{"login":"fengalin","id":28687262,"avatar_url":"https://avatars0.githubusercontent.com/u/28687262?v=4","gravatar_id":"","url":"https://api.github.com/users/fengalin","html_url":"https://github.com/fengalin","followers_url":"https://api.github.com/users/fengalin/followers","following_url":"https://api.github.com/users/fengalin/following{/other_user}","gists_url":"https://api.github.com/users/fengalin/gists{/gist_id}","starred_url":"https://api.github.com/users/fengalin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fengalin/subscriptions","organizations_url":"https://api.github.com/users/fengalin/orgs","repos_url":"https://api.github.com/users/fengalin/repos","events_url":"https://api.github.com/users/fengalin/events{/privacy}","received_events_url":"https://api.github.com/users/fengalin/received_events","type":"User","site_admin":false},"created_at":"2018-02-05T09:25:31Z","updated_at":"2018-02-05T09:25:31Z","author_association":"CONTRIBUTOR","body":"My position today is that we need a means to switch between generic and concrete types for the use cases of `gst-plugin-rs`. When the plugin is invoked from C, it will pass a generic Query. Either:\r\n\r\n- We stick to the View approach in the Rust API (e.g. in `BaseTransformImpl::query`) and we handle it the same way as for `add_pad_probe` and `set_query_function`, but sooner or later we'll have to retrieve the generic query from the View, e.g. to invoke `ffi`. I don't think it would be a good idea to use a `match` and handle all the cases for this. So at least we would need a means to switch from the View to the generic implementation directly.\r\n- Or we implement upcasting / downcasting, but then we have to deal with the MiniObject model around.\r\n\r\nIn the short term, I'm planning on exploring the followings:\r\n\r\n1. Figure out the consequences if we'd used `GstRc<_ConcreteType_>` instead of having  `GstRc<_GenericType_>` a member of `_ConcreteType_`. This way, we may be able to transfer ownership by consuming the `GstRc<_GenericType_>` into a `GstRc<_ConcreteType_>` and handle mutability nicely. Additionally, we could implement `upcast/downcast_ref`. I foresee a possible use of a `Box` due to type not being `Sized`. Would that be acceptable? I guess there are heap allocations in many places already.\r\n2. See if the approach from the first point could allow avoiding a dedicated `GstRc` and rely on Rust mechanisms only. I probably missed something here, but I feel that what we want to achieve with `GstRc` could be handled by the borrow checker, except for the `ffi` to Rust types functions of course."}}
{"actor":{"display_login":"fengalin"}}