Well was "commons-jcs" more than commons since [proxy] for instance is already very modular.
Ok so we should decide something. I think there is nothing blocking. I mean we can discuss the points you see as important and try to fix them. Taking the (simple) example of the formatting we can add checksyle/pmd/... to ensure all commits respect the correct style. If you think we can't I can propose an incubator project dedicated to JCache (would be sad honestly to not benefit from some JCS features and to get 2 different alternatives @Apache). Please let me know to let us not be blocked like it. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-22 23:32 GMT+02:00 Phil Steitz <phil.ste...@gmail.com>: > On 5/22/14, 12:45 PM, Romain Manni-Bucau wrote: > > well Now JCache is based on JCS so think almost all comments are no more > > relevant. > > > > Well if commons can't support module (jcs wouldn't be the first BTW) I > have > > no issue moving it outside of commons. This is quite common actually. > > This bothers me - and not for the reason that you may think. To > jump from another committer asking questions to "commons can't > support module" is bogus. > > Phil > > > > The point about remote mode is it is not as easy as alternatives and API > > doesn't completely fit needs of JCache, but this is not a big deal now, > we > > have something enough for now. > > > > Yes I got some formatting issues, saw a lot of classes didn't have > > organized imports but miss my settings regarding java.* was maybe not > > correct. We can fix it in all cases. > > > > > > > > > > Romain Manni-Bucau > > Twitter: @rmannibucau > > Blog: http://rmannibucau.wordpress.com/ > > LinkedIn: http://fr.linkedin.com/in/rmannibucau > > Github: https://github.com/rmannibucau > > > > > > 2014-05-22 21:37 GMT+02:00 Thomas Vandahl <t...@apache.org>: > > > >> On 22.05.14 19:24, Romain Manni-Bucau wrote: > >>> About eviction: is it still the case? Thought I removed it when merged > >> with > >>> jcs backend > >> I have no idea. I lost track when I needed to merge my changes with your > >> reformatted imports (That was one thing I forgot). Why was that > necessary? > >> > >>> Not sure I get your point about removing network/remote features, never > >>> said we should remove it but we shouldn't have it by default for > JCache. > >> You wrote: > >> ---8<--- > >> 1) I played a bit with remote cache server etc and didn't find a lot > >> of use cases, do we keep it this way (linked to 4) )? > >> 2) API: do we use JCache as main API or do we keep core? > >> 3) Reviewing JCache module I really wonder if we shouldn't use a > >> ConcurrentHashMap instead of a the currently backing CompositeCache > >> and add on top of this "locally optimized" implementation two things: > >> a) eviction (a thread regularly iterating over local items to check > >> expiry would be enough), b) distribution (see 4) ) > >> 4) distributed mode: I wonder if we shouldn't rethink it and > >> potentially add Cache<K, V> listeners usable in JCache to know if > >> another node did something (useful to get consistent stats at least - > >> basically we need a way to aggregate on each note stats) + use a key > >> for each node to keep data on a single node + potentially add backup > >> on another node. > >> ---8<--- > >> > >> JCS *has* eviction and it *can* work in a distributed environment. Many > >> people use this. > >> > >>> JCache uses JCS so once again not sure I follow. > >> See 3) above. > >> > >>> Finally extra module is quite useful when you use JCache and that's > what > >> we > >>> do in all "EE" projects cause this module doesn't depend on the > >>> implementation. > >> Yes, but we are at Commons here. I miss the willingness to discuss > >> project matters before reorganizing a project that you barely know. > >> > >> Bye, Thomas. > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
