feat: Initial Implementation of Storager #3
Conversation
|
UCloud US3's Go SDK has some differences from other object storages, so some APIs may not be handled correctly. |
| BucketHost: "api.ucloud.cn", | ||
| } | ||
|
|
||
| srv.service, err = us3.NewFileRequest(config, nil) |
There was a problem hiding this comment.
Maybe we need NewBucketRequest here, ref: https://github.com/ufilesdk-dev/ufile-gosdk/blob/master/example/demo_bucket.go?
There was a problem hiding this comment.
I think it should be NewFileRequest. Although they share the same model, us3 requires NewBucketRequest not to call file-related APIs. Like the US3 comments says.
There was a problem hiding this comment.
Maybe we should separate the creation of servicer and storager, I don't think they can share a client.
There was a problem hiding this comment.
I think it should be
NewFileRequest. Although they share the same model, us3 requiresNewBucketRequestnot to call file-related APIs.
Servicer is the container for storage. It is used to manage the bucket here in my view and just as NewBucketRequest for bucket related options.
| "time" | ||
|
|
||
| uerr "github.com/ucloud/ucloud-sdk-go/ucloud/error" | ||
| us3 "github.com/ufilesdk-dev/ufile-gosdk" |
There was a problem hiding this comment.
Ops, so confusing name of ufile here. Strange sdk.
There was a problem hiding this comment.
The predecessor of us3 is ufile.
| } | ||
|
|
||
| store = &Storage{ | ||
| client: s.service, |
There was a problem hiding this comment.
BucketName should be specified for NewFileRequest, ref: https://github.com/ufilesdk-dev/ufile-gosdk/blob/master/request.go#L48-L49.
There was a problem hiding this comment.
//Request 创建后的 instance 不是线程安全的，如果你需要做并发的操作，请创建多个 UFileRequest。
It sound like we need to store a http.Client here and create UFileRequest every time we sending API.
|
As described in #4 , we will stop the development on us3 for now. |
feat: Initial Implementation of Storager