Rude words??? It was just the right words to use, I was certainly not offended at all !!!
Le dim. 5 nov. 2017 à 13:10, Stefan Seelmann <[email protected]> a écrit : > On 11/05/2017 12:17 PM, Emmanuel Lecharny wrote: > > Never mind. I don’t have to commit everything now, I can do that after > the > > git conversion. > > > > Apacheds trunk is clean, please fell free to proceed ! > > Ok, thanks Emmanuel, and apolgize for my rude words yesterday :/ > > > Le sam. 4 nov. 2017 à 15:31, Emmanuel Lécharny <[email protected]> a > > écrit : > > > >> > >> > >> Le 04/11/2017 à 13:28, Stefan Seelmann a écrit : > >>> On 11/04/2017 12:50 PM, Emmanuel Lécharny wrote: > >>>> Hi guys, > >>>> > >>>> > >>>> I'm (slowly) reviewing the way we use cache in ApacheDS, as we need to > >>>> use one in Mavibot. Currently, we have a CacheService that is managing > >>>> the caches, hidding a bit of their initialization and such things. > >>>> > >>>> I'm not sure it's really well implemented : > >>>> > >>>> - it does not abstract the cache system we use (it's dependent on > >>>> ehcache atm) > >>>> > >>>> - it just provide a way to add a cache, remove it or get it > >>>> > >>>> - it depends on a configuration file on disk > >>>> > >>>> > >>>> The third part is really annoying, especially for those who want to > >>>> embed the system. > >>>> > >>>> > >>>> I do think we have all we need in teh ApacheDS configuration, ie the > >>>> cache size. We don't persist anything on disk, we don't use any > specific > >>>> feature related to the cache system we use. > >>>> > >>>> > >>>> Here is what I suggest we do : > >>>> > >>>> - make the CacheService cache agnostic : it should work with ehcahce > or > >>>> any other cache system we might want to use > >>>> > >>>> - mahe the Cache instance we return be an abstraction over the cache > >>>> returned by the underlying cache system > >>>> > >>>> - get rid of the configuration file > >>>> > >>>> > >>>> I don't think it would take long, it's quite isolated in the code (and > >>>> that is the only good aspect of the cache service). > >>>> > >>>> > >>>> If ayone of you have some better idea, or proposal, please feel free > to > >>>> express yourselves :-) > >>> Sound good, do that change. > >>> > >>> The only concerns I have that > >>> a) we are in the middle of svn->git migration and > >>> b) the "value" branch which already lives since March 2016, which > >>> contains changes not in trunks > >>> > >>> I really think we should do that first, finish the git migration and > >>> merge back the "value" branches, so we have one clear main development > >>> line, so other contributors are not confused. > >> > >> I don't disagree :-) > >> > >> As I said before, I have pending changes in the value branch that I > >> would like to commit before the commit, but considering the litle time I > >> have to do it properly, it's probably a good timing to commit what I > >> have, regardless of its status, do the migration, then fix the branch > >> later. > >> > >> Let me do that. > >> > >> Thanks for the feedback, Stefan. > >> > >> -- > >> Emmanuel Lecharny > >> > >> Symas.com > >> directory.apache.org > >> > >> -- > > Regards, > > Cordialement, > > Emmanuel Lécharny > > www.iktek.com > > > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
