[infinispan-dev] CacheLoader and CacheStore

[Ray Tsang]

On Thu, Aug 15, 2013 at 9:48 AM, Galder Zamarreño <galder at redhat.com> wrote:

>
> On Aug 14, 2013, at 11:14 PM, Ray Tsang <saturnism at gmail.com> wrote:
>
> > I actually did not enjoy writing parsers and config builders etc…
>
>
i felt that writing the parsers are error prone - there are many places to
touch when adding a property - maybe I just didn't follow the best
example...

i'm just thinking out loud but perhaps there is a way to consolidate the
configuration builder, configuration, configuration parser, and xsd with a
single set of metadata - after all, I think they are all trying to set the
same set of properties.



> ^ Why not? Too verbose? Too many classes?
>
> I'd rather improve this than carry on supporting property-based
> configuration (any other type safety advocates?)
>

+1, the fact that I had to test both was a nuance...





>
> Cheers,
>
> >
> > On Aug 14, 2013, at 14:58, Mircea Markus <mmarkus at redhat.com> wrote:
> >
> >>
> >> On 14 Aug 2013, at 18:48, Dennis Reed <dereed at redhat.com> wrote:
> >>
> >>>> I've written such parser on Friday, basically just copying and
> rewriting
> >>>> the SingleFileCacheStore stuff (adding my own properties instead). It
> >>>> took me about an hour and I don't hate anyone from infinispan team :)
> >>>> Maybe I am already advanced ISPN user, but I don't consider it as a
> >>>> complicated task as long as there is some template (simple cache-store
> >>>> implementation) I can use for reference.
> >>>
> >>> If it took you an hour as an advanced user that's intimately familiar
> >>> with Infinispan to implement it and get it working,
> >>> that means for many of our customers it could take days, and quite a
> few
> >>> interactions with support.
> >>>
> >>> Compare that to the current implementation where ISPN does the XML
> >>> parsing and calls setters, which takes 0 time no matter the competence
> >>> of the user.
> >>>
> >>> I'm 100% *against* forcing customers to write their own XML parsing.
> >>
> >> +1
> >> The current parsing-free approach will be kept. Just that we'll add a
> template for writing stores that would contain a sample optional parser.
> >>
> >> Cheers,
> >> --
> >> Mircea Markus
> >> Infinispan lead (www.infinispan.org)
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130815/fad7cf0a/attachment-0001.html