Skip to content

make coffer_blobserver restful #4

@benoitc

Description

@benoitc

It came to myself that the blobserver should be restful. By restful I mean resource aware and each storage should be considered as a resouce receiving messages on it.

A storage should only receive and send messages, A general abstraction on top of it should be able to forward it to another protocol if needed.

Rignt now a blob strage return an anonymous function and s state associated, but it shows its limit when you want to distribute the messages between the Erlang nodes or simply when you want to handle a remote node via HTTP, which handles by nature the messages asynchronously.

A storage server would receive the following:

Storage requests

Message:

{storage_request, From, ReplyAs, Request}
  • From: Pid of the process making the request
  • ReplyAs: Reference
  • Request: a request

Requests on a storage for now can be:

  • capabilities : get all the capabilties
  • {enumerate, Options}: get the lists of blobs in this storage
  • {setopts, Options}: replace the storage' options for the properties given
  • getopts: get the storage' options

If an index is associated to the storage we can also have

  • {search, Args}

blob request:

Message:

{blob_request, From, ReplyAs, Request}
  • From: Pid of the process making the request
  • ReplyAs: Reference
  • Request: a request

Request can be:

  • {fetch, BlobRef} : return {ok, ReaderStream} | {error, not_found} . ReaderStream is a reference to an stream opened by the storage handler to fetch the blob content. remotely or not.
  • {receive, BlobRef}: return {ok, WriterStream} | {error, already_exists} | {error, term()} . WriterStream os a stream opened by the storage handler to store the content remotely or not.
  • {delete, BlobRef}: : return ok | {error, not_found} | {error, term()} . To delete a blob.

A ReaderStream send messages to the requesting process:

  • {Ref, {ok, Data}} : binary data
  • {Ref, {ok, Data, Ranges}} : return only some part of the blob to support range requests. A range is a list of tuple {Start, End} where {Start, End} are positions in the blob (in bytes).
  • {Ref, eob} : end of the blob
  • {error, term()}: an error happened

A WriterStream receive messages from the requesting process:

  • {Ref, {ok, Data}} : binary data
  • {Ref, eob} : end of the blob
  • {error, term()}: an error happened

Note:

  • A writer should always make sure that a blob with the same reference is not actually uploaded. If an error happen, it should remove any stored content.
  • A storage should efficiently store blobs so he can respond to the ranges requests

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions