Xuanwo commented on PR #3004:
URL: 
https://github.com/apache/incubator-opendal/pull/3004#issuecomment-1704699102

   > If we use boost to provide a more high-level API.
   
   Yes, I prefer to have a more high-level API. OpenDAL's Reader is not a 
underlying file object and can't be operated as a file.
   
   ---
   
   What makes me feel the most uneasy is the direction of our cpp binding. 
Let's revisit the VISION for our opendal binding: to provide a native 
experience and easier-to-maintain bindings based on opendal.
   
   - Naitve Experience: Makes OpenDAL looks like written in Cpp
   - Easier to maintain: Make maintainers for both rust core and cpp bindings 
happy
   
   So our bindings is composed by two parts: `ffi` and `cpp`.
   
   - `ffi` is used to expose rust structs to cpp structs, it's just a bridge.
   - `cpp` is used to build public API for users.
   
   Take a naming issue as an example:
   
   
![image](https://github.com/apache/incubator-opendal/assets/5351546/fb502bb0-9387-457a-b843-f1637a2d9f14)
   
   It does ok to expose as just `fill_buf`, but:
   
   - Users should not call `fill_buf` as first, it's not the public API we want 
to expose. (are you agree with this?)
   - `fill_buf` is confused with other APIs. I prefer to have something that 
`opendal::ffi::reader_fill_buf`, and our cpp code should call 
`opendal::ffi::reader_fill_buf` internally.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to