Thanks for chiming in. some notes on notes below! > through jclouds. This conversion not only makes jclouds needlessly at > the whim of guava compatibility, but is also unnecessarily expensive.
Perhaps, but are these the biggest pain points for users/devs? The Guava compatibility fiasco is admittedly frustrating, but hopefully rare going forward. Guava prevents blobstore (and jclouds) from being considered many android environments. Guava compatibility is not only a frustration, but a non-starter for folks who write frameworks. This thread is thoroughly discussed elsewhere. We don't need a guava dep for blobstore so can avoid this class of problems completely in the future. For example, once our views stop propagating guava, we can clean it from core. This is clearly not your biggest concern, but believe me, being the author of jclouds and not being able to use it in most recent companies has made me quite frustrated potential user. As for pain points, IMO there are other bigger and lower hanging fruit that may be worth tackling. Two concrete examples that are not blobstore specific: 1. URL encoding/decoding issues: https://issues.apache.org/jira/browse/JCLOUDS-217 Agreed this isn't blobstore specific and more a favorite bug. 2. RestAnnotationProcessor magic: there are two sub-issues here actually. First is the performance overhead of all the reflection that happens to make this work. I've not measured it, but we have run into cases in the past where reflection added non-trivial overhead (e.g. https://issues.apache.org/jira/browse/JCLOUDS-301). The second (and perhaps bigger) issue is that the code base is really hard to penetrate for new developers. At work, every new jclouds contributor has had a long ramp up and faced a steep learning curve just to figure out how things work before being able to make productive changes. And yet no-one has helped to fix this. We are amazingly capable of complaining for years, right? I already solved this in netflix feign and can obviously solve this here. Not blobstore related, but certainly and provably solvable. > In summary, I would like to fork BlobStore so that it can progress in Can you elaborate a bit more on the plans for existing blobstore and impact (if any) on existing consumers? IIUC, the proposal is to leave the current blobstore as is and develop the fork in parallel? Will there be a switch when compatibility is reached or will users always have the choice of using the legacy API? Preferably the latter, but that would double the effort for bug fixes and feature additions (e.g. implementing S3 V4 signatures). The former will require consumers to change their applications and runs the risk of introducing regressions. So neither option seems safe. Some methods as mention should have been dropped years ago. We can deprecate them now. We can also make a janky bridge once the new apis are in. Most projects evolve more than once every 5 years. we can do better, right? Even if it took us a year, it adds hope. > If anyone is interested in helping on this, let me know. I'll open a > jira in a bit. Definitely interested! What's the JIRA for this? Not created yet, but will do once I finish cleaning up other things :) Thanks for the interest!
