While I agree with michael, (it's my personal point of view on DM since even before bringing it in apache) I have to say that having a simple ready to use harness would have been useful and help adoption. That's why I adopted the Cache static facade, which well served the case. I also have to agree with daniel - this seems fluent but not so easy.
My 2 cents. Ciao, R Il giorno 19/feb/2012 05:24, "Michael André Pearce" < [email protected]> ha scritto: > Question I pose to all of this is seeing the word user, which i think > needs to be asked. > > What are you seeing DirectMemory as, a CacheStore which is the > OffHeapStore (which is what terracottas own big memory is to EHCache) which > you can plug into existing Cache Frameworks,, which the project provides > the modules to plug into such frameworks as JCR, JCache, OSCache, EHCache > etc or are you trying to write a cahce framework from scratch? > > If its a CacheStore then really i think each plugin module such as im > starting to write for EHCache and Mir is writing for JCR is where the > configuration style and method sit etc, as long as developers writing the > plugins know how to interact with the cache then that should be enough. > User will use the frameworks already existing for configuration and these > are well documented in those projects. > > If we're trying to write yet another Caching Framework, i don't personally > see the point, there are all ready good frameworks out there, and your > better off concentrating on the actual improvements of the OffHeap store, > e.g. bugs, speed, sizing needed on heap, concurrency etc. > > Mike > > > On 19 Feb 2012, at 00:43, Daniel Manzke wrote: > > > Hey guys, > > > > Simone asked me to write my 2 cents for it. ;) > > > > Due to the fact, I had a lot to do with Simone and Guice, I just can say > > that I also really like fluent apis. But reading this apis feels like > > trying to use fluent, where it doesn't fit. > > > > I often have problems with fluent apis, which have really long names for > > the method, because without them, it is not clear what they are doing. > > (because to complex?!) > > > > {code} > > /* Basic configuration APIs */ > > Cache cache = DirectMemory.createNewInstance( new > > CacheConfiguration() > > { > > > > @Override > > public void configure( CacheConfigurator cacheConfigurator ) > > { > > cacheConfigurator.buffers().count( 1 ); > > cacheConfigurator.allocate(MemoryUnit); //(or what was your > > class? ram?) > > cacheConfigurator.dispose().every(TimeUnit); > > > > cacheConfigurator.bind(Map.class).to(..); //use guice ESDL > - > > Default Implementations should > > > > //never > > have to be bound manually ;) > > cacheConfigurator.bind(MemoryManager.class).to(..); > > cacheConfigurator.bind(Serializer.class).to(..); > > } > > > > } ); > > {code} > > > > {code} > > Pointer a = cache.allocatePointer( 1 ).Gb().identifiedBy( "Simo" ); > > Pointer b = cache.put( "Strored!" ).identifiedBy( "Raf" ); > //expiring > > depends on the default of the cacheConfiguration > > Pointer b2 = cache.put( "Strored!" ).identifiedBy( "Raf" > > ).expires().in(TimeUnit); > > > > Pointer d = cache.update( new Object() ).identifiedBy( "Olivier" ); > > Pointer e = cache.updateByteArray( new byte[0] ).identifiedBy( > > "TomNaso" ) > > {code} > > > > > > Do you really have a put and putByteArray? That's hard. ;) And for my > > cases, I would add a putStream(..)? :) > > > > (we have created a cache implementation with focus on files/document > cache > > (onheap, offheap, ...)) > > > > 2012/2/19 Simone Tripodi (Created) (JIRA) <[email protected]> > > > >> Adopt fluent APIs for bootstrapping the Cache and manage stored objects > >> ----------------------------------------------------------------------- > >> > >> Key: DIRECTMEMORY-62 > >> URL: > https://issues.apache.org/jira/browse/DIRECTMEMORY-62 > >> Project: Apache DirectMemory > >> Issue Type: New Feature > >> Reporter: Simone Tripodi > >> Assignee: Simone Tripodi > >> > >> > >> Hi all guys, > >> > >> as discussed some days ago, I started prototyping an EDSL embedded in DM > >> to make Cache APIs more "sexy" :) > >> > >> So, influenced by the past experience with Commons Digester - influenced > >> by Google Guice - I tried to identify the 2 phases in the Cache > lifecycle > >> > >> * the "bootstrap" phase - where settings are used to instantiate the > >> Cache; > >> > >> * the object store management. > >> > >> Current codebase has a mix of both and users have to be aware of correct > >> sequence of operations call, I mean, calling {{Cache.retrieve( "aaa" )}} > >> without having previously called {{Cache.init( 1, Ram.Mb( 100 ) )}} at > the > >> beginning of the program, would cause an error. That is why I recurred > to a > >> kind of "configuration" pattern to make sure Cache instance have to be > >> configured first and then can be used: > >> > >> {code} > >> /* Basic configuration APIs */ > >> Cache cache = DirectMemory.createNewInstance( new > >> CacheConfiguration() > >> { > >> > >> @Override > >> public void configure( CacheConfigurator cacheConfigurator ) > >> { > >> cacheConfigurator.numberOfBuffers().ofSize( 1 ); > >> cacheConfigurator.allocateMemoryOfSize( 128 ).Mb(); > >> cacheConfigurator.scheduleDisposalEvery( 10 ).hours(); > >> > >> > >> cacheConfigurator.bindConcurrentMap().withJVMConcurrentMap(); > >> > >> > cacheConfigurator.bindMemoryManagerService().withDefaultImplamentation(); > >> > >> cacheConfigurator.bindSerializer().fromServiceProviderInterface(); > >> } > >> > >> } ); > >> {code} > >> > >> Hoping that the code itself is clear enough, the {{DirectMemory}} class > >> accepts a {{CacheConfiguration}}, users have to override the {{ > configure( > >> CacheConfigurator )}} method, where describing the basic Cache behavior, > >> and will return a Cache instance. > >> > >> According to the DRY (Don't Repeat Yourself) principle, repeating > >> "cacheConfigurator" over and over for each binding can get a little > >> tedious, so there is an abstract support class: > >> > >> {code} > >> cache = DirectMemory.createNewInstance( new > >> AbstractCacheConfiguration() > >> { > >> > >> @Override > >> protected void configure() > >> { > >> numberOfBuffers().ofSize( 1 ); > >> allocateMemoryOfSize( 128 ).Mb(); > >> scheduleDisposalEvery( 10 ).hours(); > >> > >> bindConcurrentMap().withJVMConcurrentMap(); > >> bindMemoryManagerService().withDefaultImplamentation(); > >> bindSerializer().fromServiceProviderInterface(); > >> } > >> > >> } ); > >> {code} > >> > >> Once obtained the Cache instance, users can now start storing objects: > >> > >> {code} > >> Pointer a = cache.allocatePointer( 1 ).Gb().identifiedBy( "Simo" > ); > >> Pointer b = cache.put( "Strored!" ).identifiedBy( "Raf" > >> ).thatNeverExpires(); > >> Pointer c = cache.putByteArray( new byte[0] ).identifiedBy( "Izio" > >> ).thatExpiresIn( 1 ).days(); > >> > >> Pointer d = cache.update( new Object() ).identifiedBy( "Olivier" > ); > >> Pointer e = cache.updateByteArray( new byte[0] ).identifiedBy( > >> "TomNaso" ); > >> {code} > >> > >> WDYT? > >> > >> -- > >> This message is automatically generated by JIRA. > >> If you think it was sent incorrectly, please contact your JIRA > >> administrators: > >> > https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa > >> For more information on JIRA, see: > http://www.atlassian.com/software/jira > >> > >> > >> > > > > > > -- > > Viele Grüße/Best Regards > > > > Daniel Manzke > >
