[ADBC][Rust] Proposal for Rust ADBC API

[Will Jones <wi...@gmail.com>]

Hello Arrow devs,

I have created a PR to define a Rust API for ADBC [1], meant to parallel
the ones in C, Go, and Java [2]. I'd like to get feedback on that. This API
will be considered part of the ADBC format. Once I have addressed all
feedback, we will put forward a vote for adoption into the ADBC standard.

In the meantime, I will continue prototyping the Rust driver manager and
implementation module (for building C API drivers with Rust). [3] These
prototypes informed the proposed API design and will rely on this API.
Hopefully those will be ready for review shortly after we adopt the API
standard.

Best,

Will Jones

[1] https://github.com/apache/arrow-adbc/pull/478
[2] https://arrow.apache.org/adbc/0.2.0/format/specification.html
[3] https://github.com/apache/arrow-adbc/pull/446

Re: [ADBC][Rust] Proposal for Rust ADBC API

[David Li <li...@apache.org>]

Thanks for keeping this up, Will. This sounds reasonable to me at least. 

I think stable API was more of a concern with C where it would (and did) get bound into multiple languages, multiple implementations, etc. and evolving the API is much more difficult in the first place. Hopefully Rust, Go, and Java don't have to suffer that.

On Thu, Mar 9, 2023, at 20:31, Will Jones wrote:
> I've been thinking about the process here, and I'd like to propose an
> alternate path. As I understand it, currently the process is:
>
> 1. Approve the Rust API as a stable API
> 2. "Release" Rust API as part of a new version of the ADBC format
> 3. Release Rust libraries in tandem with other ADBC libraries, matching
> their version number.
>
> On step (1), I don't think we have enough developers yet working on Rust
> ADBC to get adequate feedback on the API design to make something we want
> to be stable. I've had some time to accumulate work in WIP PRs, but still
> don't feel fully ready to declare any stable API.
>
> Also on step (3), it doesn't seem obvious to me there's a benefit for Rust
> to matching versions of other ADBC libraries. Rust's release process is
> lightweight enough where it's not much additional effort to release it
> separately. I would be willing to do that, at least initially.
>
> So I'd propose:
>
> 1. Plan to merge Rust API as "experimental", and not stabilize it until a
> little later. TBH I don't even think having a stable API in Rust is a big
> deal right now, as none of the other Rust Arrow libraries do.
> 2. Plan to release Rust ADBC library independently from other libraries,
> with its own (semantic) versioning.
>
> I think these two can be considered independently; if we find a strong
> reason to keep the Rust versions the same as other libraries, I'd still
> hope it would be fine to have the Rust API be experimental for some period.
>
> On Wed, Mar 1, 2023 at 8:12 PM Will Jones <wi...@gmail.com> wrote:
>
>> Hello Arrow devs,
>>
>> I have created a PR to define a Rust API for ADBC [1], meant to parallel
>> the ones in C, Go, and Java [2]. I'd like to get feedback on that. This API
>> will be considered part of the ADBC format. Once I have addressed all
>> feedback, we will put forward a vote for adoption into the ADBC standard.
>>
>> In the meantime, I will continue prototyping the Rust driver manager and
>> implementation module (for building C API drivers with Rust). [3] These
>> prototypes informed the proposed API design and will rely on this API.
>> Hopefully those will be ready for review shortly after we adopt the API
>> standard.
>>
>> Best,
>>
>> Will Jones
>>
>> [1] https://github.com/apache/arrow-adbc/pull/478
>> [2] https://arrow.apache.org/adbc/0.2.0/format/specification.html
>> [3] https://github.com/apache/arrow-adbc/pull/446
>>

Re: [ADBC][Rust] Proposal for Rust ADBC API

[Will Jones <wi...@gmail.com>]

I've been thinking about the process here, and I'd like to propose an
alternate path. As I understand it, currently the process is:

1. Approve the Rust API as a stable API
2. "Release" Rust API as part of a new version of the ADBC format
3. Release Rust libraries in tandem with other ADBC libraries, matching
their version number.

On step (1), I don't think we have enough developers yet working on Rust
ADBC to get adequate feedback on the API design to make something we want
to be stable. I've had some time to accumulate work in WIP PRs, but still
don't feel fully ready to declare any stable API.

Also on step (3), it doesn't seem obvious to me there's a benefit for Rust
to matching versions of other ADBC libraries. Rust's release process is
lightweight enough where it's not much additional effort to release it
separately. I would be willing to do that, at least initially.

So I'd propose:

1. Plan to merge Rust API as "experimental", and not stabilize it until a
little later. TBH I don't even think having a stable API in Rust is a big
deal right now, as none of the other Rust Arrow libraries do.
2. Plan to release Rust ADBC library independently from other libraries,
with its own (semantic) versioning.

I think these two can be considered independently; if we find a strong
reason to keep the Rust versions the same as other libraries, I'd still
hope it would be fine to have the Rust API be experimental for some period.

On Wed, Mar 1, 2023 at 8:12 PM Will Jones <wi...@gmail.com> wrote:

> Hello Arrow devs,
>
> I have created a PR to define a Rust API for ADBC [1], meant to parallel
> the ones in C, Go, and Java [2]. I'd like to get feedback on that. This API
> will be considered part of the ADBC format. Once I have addressed all
> feedback, we will put forward a vote for adoption into the ADBC standard.
>
> In the meantime, I will continue prototyping the Rust driver manager and
> implementation module (for building C API drivers with Rust). [3] These
> prototypes informed the proposed API design and will rely on this API.
> Hopefully those will be ready for review shortly after we adopt the API
> standard.
>
> Best,
>
> Will Jones
>
> [1] https://github.com/apache/arrow-adbc/pull/478
> [2] https://arrow.apache.org/adbc/0.2.0/format/specification.html
> [3] https://github.com/apache/arrow-adbc/pull/446
>