incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Manzke <daniel.man...@googlemail.com>
Subject Re: [jira] [Created] (DIRECTMEMORY-62) Adopt fluent APIs for bootstrapping the Cache and manage stored objects
Date Sun, 19 Feb 2012 13:18:10 GMT
@Memory:

cacheConfigurator.allocate( Memory.inKb(..) ); ?

Or if you would have it fluent:

cacheConfiguration.allocate().inKb(512);

Maybe this could also fit for the other ones.

Don't pass a Value to the Method and than specify the type.

-> go for method().type(value) ?

Could also fit for the dispose one.

cacheConfiguration.dispose().every().hours(33)
cacheConfiguration,dispose().never()



Bye,
Daniel

2012/2/19 Simone Tripodi <simonetripodi@apache.org>

> Salut,
>
> replying to each other :)
>
> @Daniel:
>
> > But reading this apis feels like trying to use fluent, where it doesn't
> fit.
>
> please explain the reason why :) For how long there have been cases
> where fluent APIs can/cannot be adopted? :)
>
> > cacheConfigurator.allocate(MemoryUnit); //(or what was your class? ram?)
>
> we don't have a memory model - anyway, if we had, wouldn't sound
> really fluent... how would it look?
>
> cacheConfigurator.allocate( new Ram(...) ); ?
>
> > cacheConfigurator.dispose().every(TimeUnit);
>
> same as above...
>
> > 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(..);
>
> yup, default values shall not be bound - this is something I can easily
> work on.
> Anyway this is not a DI container nor Guice :)
> cacheConfigurator.bind(...) allows too freedom... what if I, as user,
> expect if bind(MySuperRocketLauncher.class).to(...) ? Any suggestion?
>
> > Do you really have a put and putByteArray? That's hard. ;) And for my
> > cases, I would add a putStream(..)?   :)
>
> this is something we already have in the current APIs... see
> <http://s.apache.org/2o2> at lines 44, 50, 44, that is the reason why
> I added those signatures.
>
> @Michael
>
> while we are not NIH nor PFE guys... are we too happy with 3rd party
> frameworks? :)
> I mean, I really don't see DirectMemory just a backend for existing
> caching solutions - which is needed anyway, I would be the first on
> using it in production - but it is an OffHeap memory store that users
> could integrate it in their applications as well directly without any
> dependency.
>
> We are not reinventing the wheel - and I personally don't have any
> intention/time/enough energies/... to do it - but what caching
> configuration has to do with stuff in DM that already have the need to
> be configured? we configure MemoryManager, Serializer... seriously,
> that doesn't concern the cache behavior, it is pure DM stuff presented
> in a different way.
> Anyway... is "I use XXXCache wich uses YYYlang to configure it" enough
> to not offering to our users different APIs?!? Not sure that this is
> on topic with the proposal.
>
> I agree with latest Daniel's statement that "What is DM" != "DM APIs".
>
> If you want to focus your energies on fixing the concurrency level, it
> is *cool*, provide patches and we are happy to commit them, but this
> is something that doesn't have anything to concern to APIs.
>
> Anyway, that is a discussion that risks to go to nowhere and hijacks
> the thread, so I'll stop it there - and I invite you on discussing it
> in another thread.
>
> @Raf
>
> The static Cache façade is fine for some use cases and I don't intend
> dropping it, it will use the default DM configuration as already does.
> Maybe because my sample creates Cache rather than CacheService got you
> confused? may this is way you said thet is not so easy? I already have
> the code, and have coded the same style in other ASF projects...
>
> Thanks all for the feedbacks!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sun, Feb 19, 2012 at 9:26 AM, Raffaele P. Guidi
> <raffaele.p.guidi@gmail.com> wrote:
> > 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" <
> > michael.andre.pearce@me.com> 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) <jira@apache.org>
> >> >
> >> >> 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
> >>
> >>
>



-- 
Viele Grüße/Best Regards

Daniel Manzke

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message