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 >
