On 5/22/14, 11:40 PM, Romain Manni-Bucau wrote: > Well was "commons-jcs" more than commons since [proxy] for instance is > already very modular. ? - sorry I can't make any sense out of that comment. Maybe you are saying we can modularize? Sounds like a good idea. > > > 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.
I don't know anything really about [jcs], but what I think those who are interested in working on this thing need to do is come to consensus on what a new modular structure will look like, what changes make sense, what already exists vs needs to be implemented and how the changes already made are safe and effective (I got no response to a question that I asked about one of a slew of commits ripping out a lot of sync because it was "not needed" due to using CHM). Bottom line is you need to stop thinking about being "blocked" and start thinking about showing that you really understand the code and have clear ideas about where to go with it. Then you will find that you are not just "unblocked" but you have others willing to help move things along. Phil > > > > > > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
