[#73] Uploader, downloader structures refactoring #79
Labels
No labels
P0
P1
P2
P3
good first issue
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
6 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-http-gw#79
Loading…
Reference in a new issue
No description provided.
Delete branch "mbiryukova/frostfs-http-gw:feature/uploader_downloader_refactor"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #73
Signed-off-by: Marina Biryukova m.biryukova@yadro.com
e87d7939e3
tocbd95ddbcf
cbd95ddbcf
toa2a0ee8946
a2a0ee8946
to665dce78b1
Probable we can keep all handler's methods related to upload in
handler/upload.go
and methods for download inhandler/download.go
.Everything else looks good
@ -0,0 +1,558 @@
package handler
Probably we should move the
handler
package tointernal
directory.The same for
api
packageWell, this is opinionated, but let's keep it. There is no wrong or right answer for this kind of layout.
@ -0,0 +67,4 @@
// Settings stores reloading parameters, so it has to provide atomic getters and setters.
type Settings struct {
defaultTimestamp atomic.Bool
zipCompression atomic.Bool
I would use interface here instead of struct. But let's update it in #74
@ -0,0 +48,4 @@
return http.DetectContentType(buf), buf, err // to not lose io.EOF
}
func receiveFile(ctx context.Context, req request, clnt *pool.Pool, objectAddress oid.Address) {
It seems we can use
the same for
headObject
.The functions like
Handler.byAttribute
will have the following signature then665dce78b1
toc111c84613
c111c84613
tod219943542