Closing the loop. I have no immediate plans to open a jira or facilitate this. Someone else is welcome to take charge when ready!
-A On Nov 5, 2014 11:06 AM, "Adrian Cole" <adrian.f.c...@gmail.com> wrote: > 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! >
