Given the promises of the C Data Interface, it's not viable to retire the non-device versions of the interfaces. But overall, it's better to prefer only adding new things in terms of the DeviceArray structs to avoid consumers having to create duplicate interfaces for both ArrowArray and ArrowDeviceArray, particularly because the Device version is a superset of the functionality of the original ArrowArray.
Overall we want to push consumers to prefer the ArrowDeviceArray versions of interfaces since it can handle both cases (CPU and non-cpu data) and avoids the complexities of consumers having to support both with duplicate interfaces going forward. At least that's my opinion on this one. Let me know if anyone disagrees --Matt On Fri, Oct 25, 2024 at 12:21 PM Ian Cook <ianmc...@apache.org> wrote: > Thanks Matt for doing this! > > I am +0.5 on the current proposal, because (if I understand correctly) it > adds ArrowAsyncDeviceStreamHandler but does not > add ArrowAsyncStreamHandler. I recognize that the C Device Stream Interface > with a DeviceType of CPU is functionally equivalent to the C Stream > Interface, but shouldn't we specify, document, implement the non-device > version of the async interface for completeness and consistency? Please > correct me if I am misunderstanding anything here. > > Ian > > > On Fri, Oct 25, 2024 at 10:38 AM Matt Topol <zotthewiz...@gmail.com> > wrote: > > > @pitrou I've updated the format PR to add the Experimental tag to the > > header and the documentation. Thanks! > > > > On Fri, Oct 25, 2024, 7:35 AM Antoine Pitrou <anto...@python.org> wrote: > > > > > > > > +1, with the same comments as Felipe and Dewey. > > > > > > Just at one condition from me: the API should be marked experimental. > > > > > > Regards > > > > > > Antoine. > > > > > > > > > Le 24/10/2024 à 23:17, Felipe Oliveira Carvalho a écrit : > > > > +1 from me. > > > > > > > > I reviewed the PR some time ago and it's not a trivial protocol, but > > the > > > > complexity seems warranted and necessary. > > > > > > > > On Thu, Oct 24, 2024 at 6:02 PM Dewey Dunnington > > > > <de...@voltrondata.com.invalid> wrote: > > > > > > > >> Thanks Matt for putting this together! > > > >> > > > >> I was initially concerned about the complexity of the proposal; > > > >> however, it is a difficult interaction to standardize and this > > > >> proposal is not so complex that it is unimplementable. I am excited > to > > > >> use this to improve our asynchronous database access story in the R > > > >> ADBC bindings. > > > >> > > > >> +1 from me! > > > >> > > > >> -dewey > > > >> > > > >> On Wed, Oct 23, 2024 at 1:28 PM Matt Topol <zotthewiz...@gmail.com> > > > wrote: > > > >>> > > > >>> Hey All, > > > >>> > > > >>> I would like to propose a vote for us to officially add and adopt > > Async > > > >>> structures for the Arrow C Data Interface. The proposal can be > found, > > > >> along > > > >>> with discussion in comment threads, at [1]. The proposal contains > the > > > >>> definitions and additions to the documentation for the website. > > > >>> > > > >>> As is required, there are two implementations filed as PRs, a C++ > > > >>> implementation [2] and a Go implementation [3]. > > > >>> > > > >>> The vote will be open for at least 72 hours. > > > >>> > > > >>> [ ] +1 Accept the proposal > > > >>> [ ] +0 > > > >>> [ ] -1 Do not accept this proposal because... > > > >>> > > > >>> Thanks everyone! > > > >>> --Matt > > > >>> > > > >>> [1]: https://github.com/apache/arrow/pull/43632 > > > >>> [2]: https://github.com/apache/arrow/pull/44495 > > > >>> [3]: https://github.com/apache/arrow-go/pull/169 > > > >> > > > > > > > > > >
