OK, then we're on the same page, just wanted to verify. Re the design doc wrt interceptors, contact Radim Cheers
On 20/03/15 10:18, Galder Zamarreño wrote: > >> On 14 Mar 2015, at 09:39, Bela Ban <b...@redhat.com> wrote: >> >> Hi Galder, >> >> apologies for the long reply ! > > Haha, it's still sorter than my proposal, so not too bad :) > >> imo the value of Java 8 is: >> >> #1 Reduction of implementation code (streams and internal iteration) >> >> #2 Making some of the APIs simpler, e.g. distributed executors, map-reduce >> >> #3 Reactive programming, e.g. interceptor chain (discussed in Berlin), >> non-blocking behavior; the goal being to reduce the number of threads >> required. > > I've heard a lot about ^, looking forward to seeing design doc. > > I was discussing Java 8 API with others while you were having this discussion. > >> However, changing the entire Cache API is going too far atm. Now that >> we've finally provided a Cache/JSR107 API, people are familiar with it >> and I would not change it, at least not right now. > > You are missing essence of the proposal: > > There's no unique way in which people want to access a Cache. Some people > want to use ConcurrentMap, others want to use JSR-107 Cache API, others > might want to use Infinispan 7 Cache API, others just want to store data and > run map/reduce jobs... > > I'm not suggesting that we change the entire Cache API. What I'm suggesting > is this: Java 8 allows us the vast majority of caching use cases to be > distilled into a reduced, flexible API, which can be the foundation for the > facade's that we offer. > > IOW, we're not forcing anyone to use the new Cache API. If you want, you can, > but the vast majority of users will use APIs they know (JSR-107, > java.util.concurrent). > > It's about choice, not about having a new main API. IOW, use whatever API you > want, but if youw want flexibility, we have something for you that will allow > you to build more interesting data structures on top of this functional cache > API. > >> If we're able to use reactive programming (e.g. your eval() function) >> *under the cover*, then all the better. >> >> If your proposal is about providing FunctionalCache and implementing >> Cache and JSR 107 Cache with it, then you have my +1. But IMO >> FunctionalCache should not be the main API. > > ^ You're getting main point but you are wrongly believing that I want > Functional Cache to be the main API. > > Functional Cache will offer the basis to provide whatever API you want, but > it should never be the first choice for users to use. > > IMO, the users of Functional Cache would be advanced users that say, want to > build a distributed queue on top of Infinispan. > > There should not be a main API going forward, but choice: JSR-107 API, > java.util.concurrent...,etc > >> Compare FunctionalCache.eval() to ioctl() for a moment: of course, every >> access to a file system can be implemented via ioctl(), but people like >> the simplicity of write(), read(), stat() etc. >> >> So providing eval() *only* shifts the burden of implementation to the >> user. But I agree that perhaps it's a good thing to expose >> FunctionalCache so power users (e.g. Sanne :-)) can use it directly to >> implement functionality not provided by Cache. > > +1000, that's precisely the vision I have, but again Functional Cache is not > forced on them. > >> Being able to switch to Java 8 doesn't imply we have to use all of its >> new features. > > Totally. > >> >> Let me address your proposal step by step. >> >> >> >> "What's wrong with the Infinispan Cache API?" >> -------------------------------------- >> - Nothing ! >> - I can't follow your argument as to why Cache is bad. This is the >> premise to your proposal and it needs to be very clear ! >> - JSR 107 came up with a similar API. So if we have to change Cache, >> then I'd +1 a change to JSR 107 as main API >> - I don't see why it's difficult to add new operations: distributed >> queues should be a separate API anyway, and not extend Cache ! We should >> use CacheManager to get a new DistributedQueue, as we do to get a new >> Cache... > > ^ Right, I think all this section needs to be rewritten to avoid confusion. > >> >> >> "How does Java 8 improve on this?" >> ------------------------------ >> - Passing serialized lambdas around sounds awfully familiar: it's the >> old 'agent-based programming' paradigm fashionable before the turn of >> the millenium. Instead of invoking RPCs which carry data on P, code >> (also carrying data) is shipped to P and executed there and the result >> sent back to the invoker. (Disclaimer: I wrote such a system myself with >> GOMScript... :-(). >> I'm not saying this is bad, but we have to make sure that >> (a) Infinispan benefits from this either in code reduction / >> maintainability / code simplification >> (b) performance doesn't decrease > > ^ +1, performance at least for the most critical operations, e.g. put/get, > needs to be at least on par. > >> >> >> >> "Proposal" >> --------- >> - Returning a CompletableFuture is a good idea: +1 >> - I think this is where the main value of your proposal lies: being able >> to chain functions (lambdas) together, that are invoked turn-by-turn, >> possibly by different threads, without a caller having to block >> - The F.invoke(G).andThenInvoke(H).andThenInvoke(I) pattern (where F is >> a future and G,H,I are lambdas) is very valuable to implement >> non-blocking behavior: whenever a function (lambda) has to block, it >> registers a function with the blocking resource that's called upon >> unblocking and the thread terminates and is added back to the thread pool >> - Blocking can be waiting to read from the file system or network, or >> trying to acquire a lock etc >> - As was discussed in Berlin, the interceptor chain could be rewritten >> using CompletableFutures (or sth similar). > > ^ Yeah, there's a lot of value to be added in this area. > > I was very pleased to hear about the CompletableFuture based interceptor > chain discussion because I thought it'd fit perfectly with the direction of > the functional cache API. > >> >> >> Summary >> -------- >> >> I'd not make FunctionalCache the main API and I'd definitely not >> deprecate Cache. > > Ok, maybe we won't deprecate Infinispan Cache but we'll definitely won't add > anything extra there. It's way too ovebloated IMO. > >> >> +1 on providing FunctionalCache as a (parent) interface to Cache, so >> power users can use FunctionalCache if needed. >> >> +1 on implementing Cache and JSR 107 Cache with FunctionalCache. >> >> This should only be done if: >> - Performance remains at least as good as it is now [mandatory] >> - Maintainability increases [nice] >> - Code reduction [nice] >> >> My 5 cents > > +1 to all those. > > Thanks Bela for the feedback! > >> >> >> On 13/03/15 09:10, Galder Zamarreño wrote: >>> Hi all, >>> >>> We're starting to work on some prototypes for the Java 8 API coming up in >>> Infinispan 8. >>> >>> I've written a design wiki for a replacement of our main embedded Cache >>> interface that takes advantage of Java 8 improvements: >>> https://github.com/infinispan/infinispan/wiki/Java-8-API-proposal >>> >>> It'd be great to hear your thoughts. >>> >>> Proposals for Java 8 versions for cache manager, remote cache and other >>> external APIs are yet TBD. >>> >>> Regards, >>> -- >>> Galder Zamarreño >>> gal...@redhat.com >> >> -- >> Bela Ban, JGroups lead (http://www.jgroups.org) >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Galder Zamarreño > gal...@redhat.com > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
