> Would you be looking to maintain the same basic interfaces (such as
> BlobStore itself) and reimplement those, or do you have a totally new design
> in mind here?
BlobStore itself actually had no guava dependency and was simple for a
long time. It is more the payload part and content metadata that have
become fused, ex preferring to separately control payload and its
length now, etc. It is possible to undo that, but yeah I've spent way
too much time on tasks like this to continue, then have to deprecate
what was added etc.
One idea is just doing the samish interface, but no guava, mutable
content metadata, or dicey/concurrent ops (ex. scatter-gather clear,
extract out mpu separately).
Ex. Iterator<ListPage<Container>> list = blobstore.listContainers();
// vs fluent iterable subclassing
Ex. MPUploader uploader = blobstore.uploaderFor(container, blobName);
// vs dodgy internal stuff
Ex. boolean couldDelete = blobstore.tryDelete(container); // vs us
manage concurrency
if (!couldDelete) { // let users use one of a billion ways to clear a
container in their favorite lang or library, most of which better than
our internal code.
Stream.of(blobstore.listBlobs())
.paralllel()
.forEach(delete);
}
Another is spiffifying
ex. design could look like this or similar, since there are only a few
domain types in BlobStore
inLocation(location).listContainers()
inContainer(container).listBlobs()
inContainer(container).putBlob(Blob.create("/apple", "hello world"));
// or longer form
or ..
containersIn(location).list()
blobsIn(container).list()
blobsIn(container).put(Blob.create("/apple", "hello world")); // or longer form
>
> Background to the question is that the changes you describe sound like they
> would be useful for jclouds BlobStore users in general, and if possible it
> would obviously be nice if existing users could also easily use this new
> version.
For example, when I wrote the openstack-swift api, which started
towards multi-region and less crazy interface delegation, I threw an
exception on countBlobs.
At any rate, there are 2 different issues here.
1. We've overguaved blobstore without making it any better than it
was. I'm tired of chasing that and frustrated from having to
constantly be bogged down with guava related messes, particularly
backports. Someone else can help revert the guavification
independently of this if they care. They could also deprecate the
known dodgy methods! That would make a bridge to the next api easier.
2. Unlike a lot of code, blobstore has not been modernized (in the
meaningful sense, ex design) in a long time. We've continued to expose
things that should have been deprecated and removed a long time ago,
choosing to focus our time chasing guava. BlobStore needs a facelift
as evidenced by multi-region, MPU, etc. No-one has done that in a
couple years, so I assume that my offer to help will be a welcome
change.
For transition, we made View so that we can expose multiple
interfaces, and I recall computeservice 2 as being discussed as a use
case for it. one could build a context with the new interface. If
someone writes a bridge to the old, that can be used and we can
eventually deprecate the old one.
At any rate, this carves out a less annoying area to do meaningful work.
>
> ap
