feat(bindings/dart): Add dart binding #5591
Conversation
asukaminato0721
changed the title
asukaminato0721
force-pushed
the
dart-binding
branch
from
3c3e299 to
4c71c47
Compare
|
I only ported part of the apis so the test can pass. And currently all result is using unwrap (as a first version). |
asukaminato0721
force-pushed
the
dart-binding
branch
from
17b22c8 to
4cdbabe
Compare
|
Thank you so much, @asukaminato0721, for working on this. I will start reviewing this PR later next week. Wishing you a wonderful holiday in the meantime! |
asukaminato0721
force-pushed
the
dart-binding
branch
from
4cdbabe to
c795426
Compare
| abstract class Operator implements RustOpaqueInterface { | ||
| Capability capability(); | ||
|
|
||
| Future<void> check(); | ||
|
|
||
| Future<void> createDir({required String path}); | ||
|
|
||
| void createDirSync({required String path}); | ||
|
|
||
| Future<void> delete({required String path}); | ||
|
|
||
| void deleteSync({required String path}); | ||
|
|
||
| Future<bool> isExist({required String path}); | ||
|
|
||
| bool isExistSync({required String path}); | ||
|
|
||
| factory Operator( | ||
| {required String schemeStr, required Map<String, String> map}) => | ||
| RustLib.instance.api | ||
| .crateApiOpendalApiOperatorNew(schemeStr: schemeStr, map: map); | ||
|
|
||
| Future<void> rename({required String from, required String to}); | ||
|
|
||
| void renameSync({required String from, required String to}); | ||
|
|
||
| Future<Metadata> stat({required String path}); | ||
|
|
||
| Metadata statSync({required String path}); | ||
| } |
There was a problem hiding this comment.
I noticed that we are following the same way of rust's API. Does dart use this same API pattern? Maybe we can take it's fs API or s3 SDK for an example.
There was a problem hiding this comment.
Does dart use this same API pattern
yes, dart just change from like rename_sync to renameSync.
There was a problem hiding this comment.
in the lib/opendal_test.dart file, there are some test cases.
There was a problem hiding this comment.
Hi, sorry for not making my statement clearer. What I want to know is how native Dart users perceive these APIs. Does our current API design meet their expectations?
For example, dart-io's API looks in this way: https://api.dart.dev/dart-io/dart-io-library.html
import 'dart:io';
void main() async {
final filename = 'file.txt';
var file = await File(filename).writeAsString('some content');
// Do something with the file.
}
There was a problem hiding this comment.
I get it. User can just import them and use them like native.
There was a problem hiding this comment.
Hi, I'm afraid we're still not on the same page. What I want to ask is how users feel about this library—will it feel native to them? Will they appreciate this API design?
Take dart:io as an example. Should we expose a File class and provide methods like rename and write on it? Or is it a widely accepted API design pattern to have a struct that provides all the necessary APIs?
Finally, is it a good idea to introduce something called Operator in the Dart ecosystem? Do they have a similar concept?
In short, how will we design a native library in dart that allows users to access all storage services? Fortunately, it's powered by OpenDAL.
There was a problem hiding this comment.
Let's take other bindings as examples:
- Python expsoes
Fileto users. - Java exposes
InputStreamandOutputStreamto users.
What's the similiar concept in dart?
Which issue does this PR close?
Closes #2435. Use the same way as https://github.com/open-spaced-repetition/fsrs-rs-dart.
Rationale for this change
What changes are included in this PR?
add dart binding
Are there any user-facing changes?
no