basically I respected all remarks, only pendings ones are: 1) modules 2) I removed Serializable from *API* of auxilary caches since it prevent a lot of things like using it only in memory on not serializable objects for instance. The constraint is still on the impl which need it but not more in the API 3) I removed "Seconds" suffix in configuration since for JCache we need it to be millisecond. Default is still in second (without the suffix) but we need this update otherwise we can't pass JCache tests
@Thomas: anything I forgotten, thinks that's all now? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-05-24 20:09 GMT+02:00 Phil Steitz <phil.ste...@gmail.com>: > On 5/24/14, 10:46 AM, Romain Manni-Bucau wrote: > > Hi > > > > > > 2014-05-24 19:42 GMT+02:00 Phil Steitz <phil.ste...@gmail.com>: > > > >> 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. > > was to fix my previous sentence where I used 'commons' instead of > > 'commons-jcs'. But not that important > > > > > >> > > >>> 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. > >> > > > > Globally agree. About modular since I was not alone doing it I thought it > > was ok. Main reason I said we were blocked is the fact each time > something > > needs to be fixed mail are "don't do it", instead of "we should go this > > way" with specific pointers and with an important delay for dev phase. > > > > If Thomas only checks his mails once a week it can explain it BTW. > > I would suggest that you try once more to summarize what you are > trying to do, responding to Thomas' objections, maybe suggest some > compromises, move forward with stuff all can agree on and keep > working on consensus for the other stuff. > > Phil > > > > > >> 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 > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
