Hi, team. In looking through changes of late, our BlobStore is now quite tangled with guava. For example, we now primarily use complex types like MediaType and Hash to represent values that often pass directly through jclouds. This conversion not only makes jclouds needlessly at the whim of guava compatibility, but is also unnecessarily expensive.
For example, the Content-MD5 header is used as a part of conditional ops. converting that to and from a guava object doesn't help unless in the case users are storing a serialized form of the guava object. Since Content-MD5 is a serialized form, this is just thrashing when applied to the common context of http. Another example: Payload starting to weld itself to ByteSource. This direction makes me very uneasy for reasons mentioned earlier, including that no http transport actually consumes that type! Moreover, pre-buffered types like strings, arrays, and files are already special-cased in most IO transports. While undoing the above is possible, I'm getting tired of the constant work in this vein. Rather than chase around, continuing to undo the last year's questionable guava proliferation, it would be more pleasant to just start over. In summary, I would like to fork BlobStore so that it can progress in a way that does not require using guava for everything, or unwrapping standard http headers in a very expensive way, just so we can re-wrap them again. The only times we should consider unwrapping values is when there's code that needs to act on them as such (think cache-control). Otherwise, leave them alone. please. and don't make users give us expensive things! As a part of this, I can also divorce BlobStore from the mutable hierarchy, set bias, and kooky expensive ops like countBlobs. The new BlobStore will have a good chance at running on android, for reasons including ditching guava. I will like it again, and that will help me want to continue to maintain it. If anyone is interested in helping on this, let me know. I'll open a jira in a bit. -A
