https://issues.apache.org/jira/browse/JCLOUDS-770 on this techdebt area. I'll use the other branch of this thread to discuss blobstore-relevant topics.
On Wed, Nov 5, 2014 at 12:05 PM, Adrian Cole <adrian.f.c...@gmail.com> wrote: > Pps we can't change restannotationprocessor yet anyway because not only have > we not moved off the deprecated approach of expect tests, we still have > tests that use the even older restannotationprocessortest! > > Iotw, if anyone has time to offer and wanta to make it count, please migrate > off deprecated test frameworks (or at least atop making new tests with > them!) and onto MWS. > > Not only is this a better idea anyway, it reduces the backlog of work needed > to even start fixing core. > > -A > > On Nov 5, 2014 11:17 AM, "Adrian Cole" <adrian.f.c...@gmail.com> wrote: >> >> PS one of my largest disappointments is that folks haven't helped with >> things discussed for years on RestAnnotationProcessor. For example, we >> had a plan to deprecate and remove the async interfaces that required >> a lot of the complexity there. That started and then it literally >> waited until I did all of the rest of the cleaning over a weekend. >> When we really care about something, and want to make things better, >> chipping in to complete rudimentary tasks is the best way to preserve >> time for folks like me who can help address complex core issues. >> >> Relying on one person to not only improve core, but also address >> deprecation cleanup of, in this case most async apis outside openstack >> is a great way of ensuring success. There's plenty of other known >> problem road fixes left as presents for me personally, such as moving >> off Expect tests, which are horribly difficult to debug, and trip >> builds etc. >> >> Long story short, (and this is addressed to devs, not Diwaker) put >> skin in the game, vote with your pull requests, clear path for core >> changes if you can't do them yourselves. This will facilitate the >> ability to get changes we all want in. >> >> /me ends soap box >> >> On Wed, Nov 5, 2014 at 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!
