Chiming in as a user and occasional contributor here. I agree BlobStore can use some modernization and in its current state its both hard to make changes and attract new developers. But forks are risky. Comments inline.
On Mon, Nov 3, 2014 at 10:27 PM, Adrian Cole <adrian.f.c...@gmail.com> wrote: > 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. 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 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. > 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. > 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? -- http://maginatics.com
