8:21 p.m.
Hi,
Apologies for the long email :-)
There have been several discussions around how the CacheStore and CacheLoader
functionality should look in the new CacheLoader API.
Here's are the possible approaches:
1. Have CacheLoader and CacheWriter as independent interfaces, the way JSR 107 does it
([1][2]). Note that CacheWriter does not extend CacheLoader.
Pros:
a. [major] follows the JSR-107 standard, in future people might be used to this way of
implementing stuff
b. [minor] a cleaner design: people can only implement a CacheLoader if all they do is
load data
Cons:
c. tricky to configure in XML: we use the "loader" tag for configuring a
CacheLoader. A "writer" (or "store" as we do now) tag for configuring
a CacheWriter. But what are we going to use in order to configure something that
implements both CacheLoader and CacheWriter? "writer" as we do now? or allow
both? or require one to configure the same entity both as a "loader" and as a
"writer"? The later would make the most sense but I think would result in a
configuration nightmare.
d. The terms "cache loader" and "cache store" are used
interchangeably which causes confusion through the users.
2. Have a sigle interface that exposes the all the methods from CacheLoader and
CacheWriter. (Name it CacheLoader?)
Pros:
a. [major] clear and simple configuration. avoid confusion throughout the users
b. [minor] most of the API implementors implement both loaders and stores. They'd
only have to deal with a single SPI interface for this
Cons:
c. doesn't follow exactly JSR-107's way of doing things.
d. people that only need to load data would need to leave the store methods empty. Not
as nice as having a specific interface for it.
3. Stick to the current approach of having CacheWriter extends CacheLoader
Pros:
a. [minor] a cleaner design: people can only implement a CacheLoader if all they do is
load data
b. [minor] clear configuration. we'd use "loader" and "writer"
tags (as we do now)
Cons:
c. The terms "cache loader" and "cache store" are used
interchangeably which causes confusion through the users
My personal preference is for 2 because of simplicity.
Opinions?
[1]
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
[2]
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
11:28 p.m.
My vote is #2, as it simplifies the code and removes redundant code
(fewer chances for bugs).
We've already had to fix one bug where the code reading the cache loader
configuration was different than reading the cache store configuration.
-Dennis
On 08/09/2013 01:21 PM, Mircea Markus wrote:
Hi,
Apologies for the long email :-)
There have been several discussions around how the CacheStore and CacheLoader
functionality should look in the new CacheLoader API.
Here's are the possible approaches:
1. Have CacheLoader and CacheWriter as independent interfaces, the way JSR 107 does it
([1][2]). Note that CacheWriter does not extend CacheLoader.
Pros:
a. [major] follows the JSR-107 standard, in future people might be used to this way
of implementing stuff
b. [minor] a cleaner design: people can only implement a CacheLoader if all they do is
load data
Cons:
c. tricky to configure in XML: we use the "loader" tag for configuring a
CacheLoader. A "writer" (or "store" as we do now) tag for configuring
a CacheWriter. But what are we going to use in order to configure something that
implements both CacheLoader and CacheWriter? "writer" as we do now? or allow
both? or require one to configure the same entity both as a "loader" and as a
"writer"? The later would make the most sense but I think would result in a
configuration nightmare.
d. The terms "cache loader" and "cache store" are used
interchangeably which causes confusion through the users.
2. Have a sigle interface that exposes the all the methods from CacheLoader and
CacheWriter. (Name it CacheLoader?)
Pros:
a. [major] clear and simple configuration. avoid confusion throughout the users
b. [minor] most of the API implementors implement both loaders and stores. They'd
only have to deal with a single SPI interface for this
Cons:
c. doesn't follow exactly JSR-107's way of doing things.
d. people that only need to load data would need to leave the store methods empty. Not
as nice as having a specific interface for it.
3. Stick to the current approach of having CacheWriter extends CacheLoader
Pros:
a. [minor] a cleaner design: people can only implement a CacheLoader if all they do is
load data
b. [minor] clear configuration. we'd use "loader" and "writer"
tags (as we do now)
Cons:
c. The terms "cache loader" and "cache store" are used
interchangeably which causes confusion through the users
My personal preference is for 2 because of simplicity.
Opinions?
[1]
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
[2]
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
Cheers,
12:49 a.m.
My vote is #1.
To get around the cf issue, how about we do something like have a tag that exposes the
functionality, not the type implemented? E.g.:
<persistence class="" readOnly="" shared="" ... >
</persistence>
----- Original Message -----
From: "Mircea Markus" <mmarkus(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Sent: Friday, 9 August, 2013 7:21:14 PM
Subject: [infinispan-dev] CacheLoader and CacheStore
Hi,
Apologies for the long email :-)
There have been several discussions around how the CacheStore and CacheLoader
functionality should look in the new CacheLoader API.
Here's are the possible approaches:
1. Have CacheLoader and CacheWriter as independent interfaces, the way JSR 107 does it
([1][2]). Note that CacheWriter does not extend CacheLoader.
Pros:
a. [major] follows the JSR-107 standard, in future people might be used to this way of
implementing stuff
b. [minor] a cleaner design: people can only implement a CacheLoader if all they do is
load data
Cons:
c. tricky to configure in XML: we use the "loader" tag for configuring a
CacheLoader. A "writer" (or "store" as we do now) tag for configuring
a CacheWriter. But what are we going to use in order to configure something that
implements both CacheLoader and CacheWriter? "writer" as we do now? or allow
both? or require one to configure the same entity both as a "loader" and as a
"writer"? The later would make the most sense but I think would result in a
configuration nightmare.
d. The terms "cache loader" and "cache store" are used
interchangeably which causes confusion through the users.
2. Have a sigle interface that exposes the all the methods from CacheLoader and
CacheWriter. (Name it CacheLoader?)
Pros:
a. [major] clear and simple configuration. avoid confusion throughout the users
b. [minor] most of the API implementors implement both loaders and stores. They'd
only have to deal with a single SPI interface for this
Cons:
c. doesn't follow exactly JSR-107's way of doing things.
d. people that only need to load data would need to leave the store methods empty. Not
as nice as having a specific interface for it.
3. Stick to the current approach of having CacheWriter extends CacheLoader
Pros:
a. [minor] a cleaner design: people can only implement a CacheLoader if all they do is
load data
b. [minor] clear configuration. we'd use "loader" and "writer"
tags (as we do now)
Cons:
c. The terms "cache loader" and "cache store" are used
interchangeably which causes confusion through the users
My personal preference is for 2 because of simplicity.
Opinions?
[1]
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
[2]
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
2:22 a.m.
On 9 Aug 2013, at 23:49, Manik Surtani <msurtani(a)redhat.com> wrote:
My vote is #1.
To get around the cf issue, how about we do something like have a tag that exposes the
functionality, not the type implemented? E.g.:
<persistence class="" readOnly="" shared="" ... >
</persistence>
It's indeed solvable, but it adds the "persistence" layer of indirection
:-)
Most of the users need read/write operations. So they'd implement a Loader and a
Writer and then configure it as a Persistence. (#1)
Or they can implement a Loader and configure it as a Loader (#2) ;)
----- Original Message -----
From: "Mircea Markus" <mmarkus(a)redhat.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Sent: Friday, 9 August, 2013 7:21:14 PM
Subject: [infinispan-dev] CacheLoader and CacheStore
Hi,
Apologies for the long email :-)
There have been several discussions around how the CacheStore and CacheLoader
functionality should look in the new CacheLoader API.
Here's are the possible approaches:
1. Have CacheLoader and CacheWriter as independent interfaces, the way JSR 107 does it
([1][2]). Note that CacheWriter does not extend CacheLoader.
Pros:
a. [major] follows the JSR-107 standard, in future people might be used to this way of
implementing stuff
b. [minor] a cleaner design: people can only implement a CacheLoader if all they do is
load data
Cons:
c. tricky to configure in XML: we use the "loader" tag for configuring a
CacheLoader. A "writer" (or "store" as we do now) tag for configuring
a CacheWriter. But what are we going to use in order to configure something that
implements both CacheLoader and CacheWriter? "writer" as we do now? or allow
both? or require one to configure the same entity both as a "loader" and as a
"writer"? The later would make the most sense but I think would result in a
configuration nightmare.
d. The terms "cache loader" and "cache store" are used
interchangeably which causes confusion through the users.
2. Have a sigle interface that exposes the all the methods from CacheLoader and
CacheWriter. (Name it CacheLoader?)
Pros:
a. [major] clear and simple configuration. avoid confusion throughout the users
b. [minor] most of the API implementors implement both loaders and stores. They'd
only have to deal with a single SPI interface for this
Cons:
c. doesn't follow exactly JSR-107's way of doing things.
d. people that only need to load data would need to leave the store methods empty. Not
as nice as having a specific interface for it.
3. Stick to the current approach of having CacheWriter extends CacheLoader
Pros:
a. [minor] a cleaner design: people can only implement a CacheLoader if all they do is
load data
b. [minor] clear configuration. we'd use "loader" and "writer"
tags (as we do now)
Cons:
c. The terms "cache loader" and "cache store" are used
interchangeably which causes confusion through the users
My personal preference is for 2 because of simplicity.
Opinions?
[1]
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
[2]
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
8:59 a.m.
My preference is for #1.
The main reason is cos JSR-107 is about to hit mainstream and we should try to align with
it in a way that we reduce confusion. Remember that JSR-107 users are potential Infinispan
users, and viceversa, so keeping these interfaces separated would make the mental effort
required to bridge the knowledge between the two easier.
I tried to go back in the JSR-107 discussions to find discussions (google group) on this
topic but couldn't find anything. Maybe Manik remembers something about it, but seems
like this topic has been pretty much set in stone for quite a while.
In terms of configuration, there's no issue at all. Each cache store provides its own
schema now. We're moving away from <loader class="x"> format. With
this in mind, given a xxxStore, Infinispan can look at the xxxStore type, cache loader or
writer, or both, we can inherently determine whether it's a read-only cache store, a
write-only one or both.
Cheers,
On Aug 10, 2013, at 2:22 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 9 Aug 2013, at 23:49, Manik Surtani <msurtani(a)redhat.com> wrote:
> My vote is #1.
>
> To get around the cf issue, how about we do something like have a tag that exposes
the functionality, not the type implemented? E.g.:
>
> <persistence class="" readOnly="" shared="" ...
>
> </persistence>
It's indeed solvable, but it adds the "persistence" layer of indirection
:-)
^ Guys, we've been moving away from this type configuration as shown in [6]. We now
have per-cache store configuration where each cache store provides its own scheme. This is
way better than the old loader+class configuration…
[6]
https://docs.jboss.org/author/display/ISPN/Cache+Loaders+and+Stores#Cache...
Most of the users need read/write operations. So they'd implement
a Loader and a Writer and then configure it as a Persistence. (#1)
Or they can implement a Loader and configure it as a Loader (#2) ;)
>
> ----- Original Message -----
> From: "Mircea Markus" <mmarkus(a)redhat.com>
> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
> Sent: Friday, 9 August, 2013 7:21:14 PM
> Subject: [infinispan-dev] CacheLoader and CacheStore
>
> Hi,
>
> Apologies for the long email :-)
>
> There have been several discussions around how the CacheStore and CacheLoader
functionality should look in the new CacheLoader API.
> Here's are the possible approaches:
>
> 1. Have CacheLoader and CacheWriter as independent interfaces, the way JSR 107 does
it ([1][2]). Note that CacheWriter does not extend CacheLoader.
> Pros:
> a. [major] follows the JSR-107 standard, in future people might be used to this way
of implementing stuff
> b. [minor] a cleaner design: people can only implement a CacheLoader if all they do
is load data
> Cons:
> c. tricky to configure in XML: we use the "loader" tag for configuring a
CacheLoader. A "writer" (or "store" as we do now) tag for configuring
a CacheWriter. But what are we going to use in order to configure something that
implements both CacheLoader and CacheWriter? "writer" as we do now? or allow
both? or require one to configure the same entity both as a "loader" and as a
"writer"? The later would make the most sense but I think would result in a
configuration nightmare.
^ Loader tag is phases out in favour of per-cache store/loader configuration where each
store provides their own schema, see [6]. So, this is not a problem.
> d. The terms "cache loader" and "cache store"
are used interchangeably which causes confusion through the users.
>
> 2. Have a sigle interface that exposes the all the methods from CacheLoader and
CacheWriter. (Name it CacheLoader?)
> Pros:
> a. [major] clear and simple configuration. avoid confusion throughout the users
> b. [minor] most of the API implementors implement both loaders and stores. They'd
only have to deal with a single SPI interface for this
> Cons:
> c. doesn't follow exactly JSR-107's way of doing things.
> d. people that only need to load data would need to leave the store methods empty.
Not as nice as having a specific interface for it.
>
> 3. Stick to the current approach of having CacheWriter extends CacheLoader
> Pros:
> a. [minor] a cleaner design: people can only implement a CacheLoader if all they do
is load data
> b. [minor] clear configuration. we'd use "loader" and
"writer" tags (as we do now)
> Cons:
> c. The terms "cache loader" and "cache store" are used
interchangeably which causes confusion through the users
>
> My personal preference is for 2 because of simplicity.
> Opinions?
>
> [1]
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
> [2]
https://github.com/jsr107/jsr107spec/blob/master/src/main/java/javax/cach...
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
12:20 p.m.
On 13 Aug 2013, at 07:59, Galder Zamarreño <galder(a)redhat.com> wrote:
My preference is for #1.
The main reason is cos JSR-107 is about to hit mainstream and we should try to align with
it in a way that we reduce confusion. Remember that JSR-107 users are potential Infinispan
users, and viceversa, so keeping these interfaces separated would make the mental effort
required to bridge the knowledge between the two easier.
I tried to go back in the JSR-107 discussions to find discussions (google group) on this
topic but couldn't find anything. Maybe Manik remembers something about it, but seems
like this topic has been pretty much set in stone for quite a while.
In terms of configuration, there's no issue at all. Each cache store provides its own
schema now.
good point. Not the custom ones though, these still need a custom tag.
We're moving away from <loader class="x"> format.
With this in mind, given a xxxStore, Infinispan can look at the xxxStore type, cache
loader or writer, or both, we can inherently determine whether it's a read-only cache
store, a write-only one or both.
Cheers,
On Aug 10, 2013, at 2:22 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
>
> On 9 Aug 2013, at 23:49, Manik Surtani <msurtani(a)redhat.com> wrote:
>
>> My vote is #1.
>>
>> To get around the cf issue, how about we do something like have a tag that
exposes the functionality, not the type implemented? E.g.:
>>
>> <persistence class="" readOnly="" shared="" ...
>
>> </persistence>
>
> It's indeed solvable, but it adds the "persistence" layer of
indirection :-)
^ Guys, we've been moving away from this type configuration as shown in [6]. We now
have per-cache store configuration where each cache store provides its own scheme. This is
way better than the old loader+class configuration…
[6]
https://docs.jboss.org/author/display/ISPN/Cache+Loaders+and+Stores#Cache...
> Most of the users need read/write operations. So they'd implement a Loader and a
Writer and then configure it as a Persistence. (#1)
> Or they can implement a Loader and configure it as a Loader (#2) ;)
>
>
>>
>> ----- Original Message -----
>> From: "Mircea Markus" <mmarkus(a)redhat.com>
>> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
>> Sent: Friday, 9 August, 2013 7:21:14 PM
>> Subject: [infinispan-dev] CacheLoader and CacheStore
>>
>> Hi,
>>
>> Apologies for the long email :-)
>>
>> There have been several discussions around how the CacheStore and CacheLoader
functionality should look in the new CacheLoader API.
>> Here's are the possible approaches:
>>
>> 1. Have CacheLoader and CacheWriter as independent interfaces, the way JSR 107
does it ([1][2]). Note that CacheWriter does not extend CacheLoader.
>> Pros:
>> a. [major] follows the JSR-107 standard, in future people might be used to this
way of implementing stuff
>> b. [minor] a cleaner design: people can only implement a CacheLoader if all they
do is load data
>> Cons:
>> c. tricky to configure in XML: we use the "loader" tag for configuring
a CacheLoader. A "writer" (or "store" as we do now) tag for
configuring a CacheWriter. But what are we going to use in order to configure something
that implements both CacheLoader and CacheWriter? "writer" as we do now? or
allow both? or require one to configure the same entity both as a "loader" and
as a "writer"? The later would make the most sense but I think would result in a
configuration nightmare.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
4:30 p.m.
On Aug 13, 2013, at 12:20 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 13 Aug 2013, at 07:59, Galder Zamarreño <galder(a)redhat.com>
wrote:
> My preference is for #1.
>
> The main reason is cos JSR-107 is about to hit mainstream and we should try to align
with it in a way that we reduce confusion. Remember that JSR-107 users are potential
Infinispan users, and viceversa, so keeping these interfaces separated would make the
mental effort required to bridge the knowledge between the two easier.
>
> I tried to go back in the JSR-107 discussions to find discussions (google group) on
this topic but couldn't find anything. Maybe Manik remembers something about it, but
seems like this topic has been pretty much set in stone for quite a while.
>
> In terms of configuration, there's no issue at all. Each cache store provides its
own schema now.
good point. Not the custom ones though, these still need a custom tag.
^ No, we don't, or if we currently do, we shouldn't stop doing so.
IOW, even those who want to create a custom cache store should follow the same pattern of
providing their own XML schema parser for their config, configuration builder files…etc.
That gets rid of the problem altogether, and by checking the type of the cache
loader/store, we can figure out whether it's read-only, write-only or read-write
(assuming we keep the interfaces separated).
Cheers,
> We're moving away from <loader class="x"> format. With this in
mind, given a xxxStore, Infinispan can look at the xxxStore type, cache loader or writer,
or both, we can inherently determine whether it's a read-only cache store, a
write-only one or both.
>
> Cheers,
>
> On Aug 10, 2013, at 2:22 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
>
>>
>> On 9 Aug 2013, at 23:49, Manik Surtani <msurtani(a)redhat.com> wrote:
>>
>>> My vote is #1.
>>>
>>> To get around the cf issue, how about we do something like have a tag that
exposes the functionality, not the type implemented? E.g.:
>>>
>>> <persistence class="" readOnly="" shared=""
... >
>>> </persistence>
>>
>> It's indeed solvable, but it adds the "persistence" layer of
indirection :-)
>
> ^ Guys, we've been moving away from this type configuration as shown in [6]. We
now have per-cache store configuration where each cache store provides its own scheme.
This is way better than the old loader+class configuration…
>
> [6]
https://docs.jboss.org/author/display/ISPN/Cache+Loaders+and+Stores#Cache...
>
>> Most of the users need read/write operations. So they'd implement a Loader
and a Writer and then configure it as a Persistence. (#1)
>> Or they can implement a Loader and configure it as a Loader (#2) ;)
>>
>>
>>>
>>> ----- Original Message -----
>>> From: "Mircea Markus" <mmarkus(a)redhat.com>
>>> To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
>>> Sent: Friday, 9 August, 2013 7:21:14 PM
>>> Subject: [infinispan-dev] CacheLoader and CacheStore
>>>
>>> Hi,
>>>
>>> Apologies for the long email :-)
>>>
>>> There have been several discussions around how the CacheStore and CacheLoader
functionality should look in the new CacheLoader API.
>>> Here's are the possible approaches:
>>>
>>> 1. Have CacheLoader and CacheWriter as independent interfaces, the way JSR
107 does it ([1][2]). Note that CacheWriter does not extend CacheLoader.
>>> Pros:
>>> a. [major] follows the JSR-107 standard, in future people might be used to
this way of implementing stuff
>>> b. [minor] a cleaner design: people can only implement a CacheLoader if all
they do is load data
>>> Cons:
>>> c. tricky to configure in XML: we use the "loader" tag for
configuring a CacheLoader. A "writer" (or "store" as we do now) tag
for configuring a CacheWriter. But what are we going to use in order to configure
something that implements both CacheLoader and CacheWriter? "writer" as we do
now? or allow both? or require one to configure the same entity both as a
"loader" and as a "writer"? The later would make the most sense but I
think would result in a configuration nightmare.
>
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
4:50 p.m.
On 13 Aug 2013, at 15:30, Galder Zamarreño <galder(a)redhat.com> wrote:
On Aug 13, 2013, at 12:20 PM, Mircea Markus
<mmarkus(a)redhat.com> wrote:
> On 13 Aug 2013, at 07:59, Galder Zamarreño <galder(a)redhat.com> wrote:
>
>> My preference is for #1.
>>
>> The main reason is cos JSR-107 is about to hit mainstream and we should try to
align with it in a way that we reduce confusion. Remember that JSR-107 users are potential
Infinispan users, and viceversa, so keeping these interfaces separated would make the
mental effort required to bridge the knowledge between the two easier.
>>
>> I tried to go back in the JSR-107 discussions to find discussions (google group)
on this topic but couldn't find anything. Maybe Manik remembers something about it,
but seems like this topic has been pretty much set in stone for quite a while.
>>
>> In terms of configuration, there's no issue at all. Each cache store provides
its own schema now.
>
>
> good point. Not the custom ones though, these still need a custom tag.
^ No, we don't, or if we currently do, we shouldn't stop doing so.
Nooo... writing a custom parser for a custom cache store is quite a bit of work and
requires understanding of ISPN configuration hierarchy. People would hate us! E.g. the
jdbc one: http://goo.gl/VQiQ3u
IOW, even those who want to create a custom cache store should follow the same pattern of
providing their own XML schema parser for their config, configuration builder files…etc.
That gets rid of the problem altogether, and by checking the type of the cache
loader/store, we can figure out whether it's read-only, write-only or read-write
(assuming we keep the interfaces separated).
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
11:21 a.m.
On 08/13/2013 04:50 PM, Mircea Markus wrote:
On 13 Aug 2013, at 15:30, Galder Zamarreño <galder(a)redhat.com>
wrote:
> On Aug 13, 2013, at 12:20 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
>
>> On 13 Aug 2013, at 07:59, Galder Zamarreño <galder(a)redhat.com> wrote:
>>
>>> My preference is for #1.
>>>
>>> The main reason is cos JSR-107 is about to hit mainstream and we should try
to align with it in a way that we reduce confusion. Remember that JSR-107 users are
potential Infinispan users, and viceversa, so keeping these interfaces separated would
make the mental effort required to bridge the knowledge between the two easier.
>>>
>>> I tried to go back in the JSR-107 discussions to find discussions (google
group) on this topic but couldn't find anything. Maybe Manik remembers something about
it, but seems like this topic has been pretty much set in stone for quite a while.
>>>
>>> In terms of configuration, there's no issue at all. Each cache store
provides its own schema now.
>>
>> good point. Not the custom ones though, these still need a custom tag.
> ^ No, we don't, or if we currently do, we shouldn't stop doing so.
Nooo... writing a custom parser for a custom cache store is quite a bit of work and
requires understanding of ISPN configuration hierarchy. People would hate us! E.g. the
jdbc one: http://goo.gl/VQiQ3u
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.
Just my 2c.
Radim
> IOW, even those who want to create a custom cache store should follow the same
pattern of providing their own XML schema parser for their config, configuration builder
files…etc. That gets rid of the problem altogether, and by checking the type of the cache
loader/store, we can figure out whether it's read-only, write-only or read-write
(assuming we keep the interfaces separated).
Cheers,
12:07 p.m.
On 14 Aug 2013, at 10:21, Radim Vansa <rvansa(a)redhat.com> wrote:
On 08/13/2013 04:50 PM, Mircea Markus wrote:
> On 13 Aug 2013, at 15:30, Galder Zamarreño <galder(a)redhat.com> wrote:
>
>> On Aug 13, 2013, at 12:20 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
>>
>>> On 13 Aug 2013, at 07:59, Galder Zamarreño <galder(a)redhat.com> wrote:
>>>
>>>> My preference is for #1.
>>>>
>>>> The main reason is cos JSR-107 is about to hit mainstream and we should
try to align with it in a way that we reduce confusion. Remember that JSR-107 users are
potential Infinispan users, and viceversa, so keeping these interfaces separated would
make the mental effort required to bridge the knowledge between the two easier.
>>>>
>>>> I tried to go back in the JSR-107 discussions to find discussions (google
group) on this topic but couldn't find anything. Maybe Manik remembers something about
it, but seems like this topic has been pretty much set in stone for quite a while.
>>>>
>>>> In terms of configuration, there's no issue at all. Each cache store
provides its own schema now.
>>>
>>> good point. Not the custom ones though, these still need a custom tag.
>> ^ No, we don't, or if we currently do, we shouldn't stop doing so.
> Nooo... writing a custom parser for a custom cache store is quite a bit of work and
requires understanding of ISPN configuration hierarchy. People would hate us! E.g. the
jdbc one: http://goo.gl/VQiQ3u
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.
Doesn't sounds as hard as I imagined, I'll write the sample mvn module then to see
how it goes. Thanks for the feedback.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
4:32 p.m.
On 14 Aug 2013, at 11:07, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 14 Aug 2013, at 10:21, Radim Vansa <rvansa(a)redhat.com> wrote:
> On 08/13/2013 04:50 PM, Mircea Markus wrote:
>> On 13 Aug 2013, at 15:30, Galder Zamarreño <galder(a)redhat.com> wrote:
>>
>>> On Aug 13, 2013, at 12:20 PM, Mircea Markus <mmarkus(a)redhat.com>
wrote:
>>>
>>>> On 13 Aug 2013, at 07:59, Galder Zamarreño <galder(a)redhat.com>
wrote:
>>>>
>>>>> My preference is for #1.
>>>>>
>>>>> The main reason is cos JSR-107 is about to hit mainstream and we
should try to align with it in a way that we reduce confusion. Remember that JSR-107 users
are potential Infinispan users, and viceversa, so keeping these interfaces separated would
make the mental effort required to bridge the knowledge between the two easier.
>>>>>
>>>>> I tried to go back in the JSR-107 discussions to find discussions
(google group) on this topic but couldn't find anything. Maybe Manik remembers
something about it, but seems like this topic has been pretty much set in stone for quite
a while.
>>>>>
>>>>> In terms of configuration, there's no issue at all. Each cache
store provides its own schema now.
>>>>
>>>> good point. Not the custom ones though, these still need a custom tag.
>>> ^ No, we don't, or if we currently do, we shouldn't stop doing so.
>> Nooo... writing a custom parser for a custom cache store is quite a bit of work
and requires understanding of ISPN configuration hierarchy. People would hate us! E.g. the
jdbc one: http://goo.gl/VQiQ3u
>
> 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.
Doesn't sounds as hard as I imagined, I'll write the sample mvn module then to
see how it goes. Thanks for the feedback.
Yes, having a sample maven module is definitely a good idea. And should be linked from
the documentation (perhaps in a callout section titled "Implementing your own cache
store?" :)
@Radim - feel like doing this, perhaps using the cache store that you wrote as an
example?
- M
--
Manik Surtani
7:48 p.m.
On 08/14/2013 04:21 AM, Radim Vansa wrote:
On 08/13/2013 04:50 PM, Mircea Markus wrote:
> On 13 Aug 2013, at 15:30, Galder Zamarreño <galder(a)redhat.com> wrote:
>
>> On Aug 13, 2013, at 12:20 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
>>
>>> On 13 Aug 2013, at 07:59, Galder Zamarreño <galder(a)redhat.com> wrote:
>>>
>>>> My preference is for #1.
>>>>
>>>> The main reason is cos JSR-107 is about to hit mainstream and we should
try to align with it in a way that we reduce confusion. Remember that JSR-107 users are
potential Infinispan users, and viceversa, so keeping these interfaces separated would
make the mental effort required to bridge the knowledge between the two easier.
>>>>
>>>> I tried to go back in the JSR-107 discussions to find discussions (google
group) on this topic but couldn't find anything. Maybe Manik remembers something about
it, but seems like this topic has been pretty much set in stone for quite a while.
>>>>
>>>> In terms of configuration, there's no issue at all. Each cache store
provides its own schema now.
>>> good point. Not the custom ones though, these still need a custom tag.
>> ^ No, we don't, or if we currently do, we shouldn't stop doing so.
> Nooo... writing a custom parser for a custom cache store is quite a bit of work and
requires understanding of ISPN configuration hierarchy. People would hate us! E.g. the
jdbc one: http://goo.gl/VQiQ3u
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.
-Dennis
>> IOW, even those who want to create a custom cache store should follow the same
pattern of providing their own XML schema parser for their config, configuration builder
files…etc. That gets rid of the problem altogether, and by checking the type of the cache
loader/store, we can figure out whether it's read-only, write-only or read-write
(assuming we keep the interfaces separated).
>
> Cheers,
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:58 p.m.
On 14 Aug 2013, at 18:48, Dennis Reed <dereed(a)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)
11:14 p.m.
I actually did not enjoy writing parsers and config builders etc...
On Aug 14, 2013, at 14:58, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 14 Aug 2013, at 18:48, Dennis Reed <dereed(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3:48 p.m.
On Aug 14, 2013, at 11:14 PM, Ray Tsang <saturnism(a)gmail.com> wrote:
I actually did not enjoy writing parsers and config builders etc…
^ Why not? Too verbose? Too many classes?
I'd rather improve this than carry on supporting property-based configuration (any
other type safety advocates?)
Cheers,
On Aug 14, 2013, at 14:58, Mircea Markus <mmarkus(a)redhat.com> wrote:
>
> On 14 Aug 2013, at 18:48, Dennis Reed <dereed(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
3:57 p.m.
On Thu, Aug 15, 2013 at 9:48 AM, Galder Zamarreño <galder(a)redhat.com> wrote:
On Aug 14, 2013, at 11:14 PM, Ray Tsang <saturnism(a)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(a)redhat.com> wrote:
>
>>
>> On 14 Aug 2013, at 18:48, Dennis Reed <dereed(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:45 p.m.
On 08/15/2013 03:57 PM, Ray Tsang wrote:
On Thu, Aug 15, 2013 at 9:48 AM, Galder Zamarreño <galder(a)redhat.com
<mailto:galder@redhat.com>> wrote:
On Aug 14, 2013, at 11:14 PM, Ray Tsang <saturnism(a)gmail.com
<mailto:saturnism@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.
Well, it's true that the Maven build process could generate at least the
XSD automatically, and automatic parsing is not that complicated - in
fact I've done this in RadarGun, changing Mircea's original setter-way.
But in order to be able to use the programmatic configuration, you have
either write the builder yourself or generate it with some tool (I don't
think it would be right to generate further Java sources during the
Maven build, even if it is possible). And using tool for generation of
some Java code based on another code seems to me as another nasty
complication.
Alltogether, writing *Configuration and *ConfigurationBuilder should be
enough, all the rest can be managed by runtime/build.
^ 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...
+1 as well
Radim
5:52 p.m.
On Thu, Aug 15, 2013 at 11:45 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
On 08/15/2013 03:57 PM, Ray Tsang wrote:
On Thu, Aug 15, 2013 at 9:48 AM, Galder Zamarreño <galder(a)redhat.com>wrote:
>
> On Aug 14, 2013, at 11:14 PM, Ray Tsang <saturnism(a)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.
Well, it's true that the Maven build process could generate at least the
XSD automatically, and automatic parsing is not that complicated - in fact
I've done this in RadarGun, changing Mircea's original setter-way.
But in order to be able to use the programmatic configuration, you have
either write the builder yourself or generate it with some tool (I don't
think it would be right to generate further Java sources during the Maven
build, even if it is possible). And using tool for generation of some Java
code based on another code seems to me as another nasty complication.
Alltogether, writing *Configuration and *ConfigurationBuilder should be
enough, all the rest can be managed by runtime/build.
+1. It just feel very redundant the way it is now. condensing into
Configuration and ConfigurationBuilder sounds great too, at least it's
completely typesafe at this point.
Otherwise, the way it is now, we have to keep property names in sync, and
documentation in sync, and default values in sync, etc.. and 52 parser vs
as7 parser? =(
> ^ 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...
+1 as well
Radim
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
7:03 p.m.
Could we generate the parser and/or XSD as JGroups does with
org.jgroups.annotations.Property ?
On 15 August 2013 16:52, Ray Tsang <saturnism(a)gmail.com> wrote:
On Thu, Aug 15, 2013 at 11:45 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
>
> On 08/15/2013 03:57 PM, Ray Tsang wrote:
>
>
>
>
> On Thu, Aug 15, 2013 at 9:48 AM, Galder Zamarreño <galder(a)redhat.com>
> wrote:
>>
>>
>> On Aug 14, 2013, at 11:14 PM, Ray Tsang <saturnism(a)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.
>
>
> Well, it's true that the Maven build process could generate at least the
> XSD automatically, and automatic parsing is not that complicated - in fact
> I've done this in RadarGun, changing Mircea's original setter-way.
> But in order to be able to use the programmatic configuration, you have
> either write the builder yourself or generate it with some tool (I don't
> think it would be right to generate further Java sources during the Maven
> build, even if it is possible). And using tool for generation of some Java
> code based on another code seems to me as another nasty complication.
> Alltogether, writing *Configuration and *ConfigurationBuilder should be
> enough, all the rest can be managed by runtime/build.
>
+1. It just feel very redundant the way it is now. condensing into
Configuration and ConfigurationBuilder sounds great too, at least it's
completely typesafe at this point.
Otherwise, the way it is now, we have to keep property names in sync, and
documentation in sync, and default values in sync, etc.. and 52 parser vs
as7 parser? =(
>
>
>
>
>>
>> ^ 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...
>
> +1 as well
>
> Radim
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:07 p.m.
On 15 Aug 2013, at 14:48, Galder Zamarreño <galder(a)redhat.com> wrote:
> I actually did not enjoy writing parsers and config builders
etc…
^ Why not? Too verbose? Too many classes?
I'd rather improve this than carry on supporting property-based configuration (any
other type safety advocates?)
Type safety can be enforced by requiring java-bean like properties on the configuration
object.
E.g.
<property name="timeout" value="123wrong43"/>
<property name="conction" value="blah"/> <--name of the
property misspelled -->
Both would fail to be set on the object:
XyzStoreConfig {
void setTimeout(long timeout);
void setConnection(String connection);
}
This wouldn't require writing a parser and would provide type safety. Wdyt?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
9:11 a.m.
On 08/15/2013 03:48 PM, Galder Zamarreño wrote:
On Aug 14, 2013, at 11:14 PM, Ray Tsang <saturnism(a)gmail.com>
wrote:
> I actually did not enjoy writing parsers and config builders etc…
^ Why not? Too verbose? Too many classes?
I'd rather improve this than carry on supporting property-based configuration (any
other type safety advocates?)
I agree with posts further down the thread about some over-verbose
complexity in the bean/builder/parser approach, but I'd rather have
developers go the extra mile for type safety and predictable schema.
We've been down the property based approach and it is uglier.
The JDBC store is a bad example as it is very complex in its
configuration: most of the other stores have a flat configuration and
writing a parser is not that complex really.
And while I also understand Sanne's view on auto-generated XSD, I would
only want such a tool to keep in sync the documentation between the
javadocs and the XSDs, rather than base the schema structure on the
configuration beans. Hand-written might be time-consuming initially but
I also find it helps create better, more understandable schemas.
Tristan
9:48 a.m.
On 08/14/2013 08:58 PM, Mircea Markus wrote:
On 14 Aug 2013, at 18:48, Dennis Reed <dereed(a)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 won't say days. Actually any magically called setters seem more
cryptic to me (there's even no annotation that would help me find that).
Documentation in [1] also shows only the parser-based approach. I was
rather surprised that it worked (I've started on 5.3 with the
property-based configuration).
The big advantage of the property-based approach is that everything
works out of the box, but the configuration without XSD is error-prone
to typos.
>
> 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.
Will the property based
configuration be done on the
*Configuration/*ConfigurationBuilder classes or the *Config ones? It's
confusing which one to use for a new user. The fact that the
configuration code is in org.i.configuration.cache and the business code
in org.i.loaders does not make things more clear as well.
Radim
[1]
https://docs.jboss.org/author/display/ISPN/Cache+Loaders+and+Stores#Cache...
9:14 a.m.
On 08/13/2013 08:59 AM, Galder Zamarreño wrote:
My preference is for #1.
The main reason is cos JSR-107 is about to hit mainstream and we should try to align with
it in a way that we reduce confusion. Remember that JSR-107 users are potential Infinispan
users, and viceversa, so keeping these interfaces separated would make the mental effort
required to bridge the knowledge between the two easier.
+1 for following the JSR-107 approach.
Tristan
7:28 p.m.
On Aug 20, 2013, at 8:14 AM, Tristan Tarrant <ttarrant(a)redhat.com> wrote:
> My preference is for #1.
>
> The main reason is cos JSR-107 is about to hit mainstream and we should try to align
with it in a way that we reduce confusion. Remember that JSR-107 users are potential
Infinispan users, and viceversa, so keeping these interfaces separated would make the
mental effort required to bridge the knowledge between the two easier.
>
+1 for following the JSR-107 approach.
we will.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
3900
days inactive
3920
days old
infinispan-dev@lists.jboss.org
23 comments
8 participants
participants (8)
-
Dennis Reed -
Galder Zamarreño -
Manik Surtani -
Mircea Markus -
Radim Vansa -
Ray Tsang -
Sanne Grinovero -
Tristan Tarrant