Decouple Bucket from storage operations

Applications typically interact with resources in a single bucket (there are some exceptions). The Storage interface only provides ways to deal with global resources forcing the application to pass the bucket name around as an additional string. We should add a Bucket interface that supports common operations (CRUD, Copy, Move) within a single bucket.

For example:

@Resource Bucket data;

void download(String path) {
  // do something like data.reader(path);
}

Wouldn't this work if we just provided a getObjectInfo() method on the bucket? That way, we can pass around the bucket object, and don't need duplicate useful methods?

class Bucket {
  ...

  ObjectInfo getObjectInfo(String objectName) {
    // This way I can pass around a bucket, and call getObjectInfo() on it
    // when I need the object.
    return new ObjectInfo(bucket, objectName);
  }

  ...
}

So the code you'd write is basically bucket.getObjectInfo("myfile.txt).download() or bucket.getObjectInfo("myfile.txt").delete() ?

Which makes me ask... don't we have this already?

We have BucketInfo which provides metadata about a bucket but does not allow operations on it (which makes sense for a value object). This would mean adding a Bucket interface to support operations at a Bucket level.

#55 describes a way in which this could be implemented but I opened this to generalize the issue.

OK, any chance you could update the body of the issue to clarify exactly what the end result would be in a perfect world? What would the code (that I write -- as a user) ultimately look like?

Also, there are cases where the application is just interested in the data and not the full BlobInfo e.g. to download the content it needs the data plus metadata pertinent to the response header e.g. Content-Type but not things like the Acl etc.

Sure:

public class DownloadServlet extends HttpServlet {
  @Resource Bucket data;

  public void doGet(HttpServletRequest request, HttpServletResponse response) {
    String path = request.getPathInfo();
    IOUtils.copy(data.reader(path), response.getOutputStream();
  }
}

Obviously there'd be some additional error handling and validation but that wouldn't affect the interface. A more serious implementation would also want more information about the object e.g. content-type, size, etag to add as response headers which would expand the interface. We could add a new one or add metadata methods to BlobReadChannel.

I think this is part of what I am currently working on after I renamed the Bucket and Blob data models to BucketInfo and BlobInfo (as mentioned in issue #57 and described in the GCS review doc). I thought to use issue #55 for this purpose.

The result would be functional (but not serializable) Bucket and Blob that have operations on them (such as bucket.list, bucket.getBlob,... blob.content(), blob.delete(), ..). Both Bucket and Blob would hold a reference to their associated Storage.

Storage would be changed to return (the new functional) Bucket or Blob and accept BucketInfo or BlobInfo (or just name when content is not needed).

Similarly Bucket would return Blob and accept BlobInfo.

I think this would answer for issue #55 Is there more to be done for this issue?