subject:"\[infinispan\-dev\] Dynamic Externalizers sorted for ISPN\-986 \- looking for some feedback"

Re: [infinispan-dev] Dynamic Externalizers sorted for ISPN-986 - looking for some feedback

2011-04-12 Thread Dan Berindei

+1 for Externalizer/AdvancedExternalizer.

Dan

On Tue, Apr 12, 2011 at 10:17 AM, Galder Zamarreño gal...@redhat.com wrote:

On Apr 11, 2011, at 12:06 PM, Galder Zamarreño wrote:

Guys, any thoughts on this? I want this in for BETA2...

On Apr 1, 2011, at 5:54 PM, Galder Zamarreño wrote:

Hi,

Re: https://issues.jboss.org/browse/ISPN-986

As indicated in my comments, there's two room for two types of
serialization mechanisms: one for end users and the other for SPIs.

I've got a solution for this in
https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e
and wanted to give a heads up to everyone on what it involves:

- Two separate externalizer interfaces: Externalizer (which currently, to
disrupt as little code as possible, is named EndUserExternalier) and
ExternalizerSpi or ServiceProviderExternalizer (currently named
Externalizer). The first API is basic read/write methods and the second one
with a couple of more methods for more specialised behaivour. Do people
like these names? Or can someone come up with better names? More detailed
info on the use cases in the JIRA.

I'm currently leaning towards: Externalizer (only readObject/writeObject
methods) and ExternalizerSpi (would contain the current
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/marshall/Externalizer.java)

Actually, I don't like ExternalizerSpi name, it makes configuration getters
ackward: getExternalizerSpis...

Instead I'm leaning for: Externalizer and AdvancedExternalizer which maps
very nicely with Cache and AdvancedCache and makes getters more readable:
getAdvancedExternalizers much clearer :)

- A related factor here would be to find a better name for the
XML/programmatic configuration, i.e. getServiceProviderExternalizers()?
serviceProviderExternalzer or getExternalizeSpis() externalizerSpi?
This is one thing and the other is that I'd want this XML and programmatic
configuration to be a bit hidden away cos it's specialised or for edge
cases. The obvious route the average Infinispan user should be annotation
and implement Infinispan's Externalizer interface. However, I'm don't think
there's anything special that can be done in the current architechture of
Infinispan without rethinking end user and spi configuration.

Since the XML is only relevant for the SPI version, the programmatic API
would go along the lines of getExternalizerSpis() and externalizerSpi -
Naming methods like this gives a direct link to the interface name while not
being too verbose

- To hide JBoss Marshaller details away and to simplify some of the API it
provides, I've created a new @MarshallableBy annotation that maps directly
to what JBMAR's @Externalizer does. To get an idea of the differences for
the end users, see
https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e#diff-10
as opposed to
https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e#diff-9.
Are people happy with the annotation name? The cool thing is that if
someone wants to really use JBoss Marshaller Externalizers, they can, but I
think the majority will be happy with just a read/write object method.

And that's about it! Afterwards it just needs proper documentation in wiki
and javadocs, but right now I'm mostly focused at getting naming right.
Thoughts?

Ideally I'd like to get this into BETA1 (release date next Tuesday, 5th
April), but I'll prob hold till BETA2 to get the naming right.

Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache

___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Dynamic Externalizers sorted for ISPN-986 - looking for some feedback

2011-04-12 Thread Mircea Markus

On 12 Apr 2011, at 10:51, Dan Berindei wrote:

+1 for Externalizer/AdvancedExternalizer.
+1, we already do that for Cache/AdvancedCache.

Dan

On Tue, Apr 12, 2011 at 10:17 AM, Galder Zamarreño gal...@redhat.com wrote:

On Apr 11, 2011, at 12:06 PM, Galder Zamarreño wrote:

Guys, any thoughts on this? I want this in for BETA2...

On Apr 1, 2011, at 5:54 PM, Galder Zamarreño wrote:

Hi,

Re: https://issues.jboss.org/browse/ISPN-986

As indicated in my comments, there's two room for two types of
serialization mechanisms: one for end users and the other for SPIs.

I've got a solution for this in
https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e
and wanted to give a heads up to everyone on what it involves:

- Two separate externalizer interfaces: Externalizer (which currently, to
disrupt as little code as possible, is named EndUserExternalier) and
ExternalizerSpi or ServiceProviderExternalizer (currently named
Externalizer). The first API is basic read/write methods and the second
one with a couple of more methods for more specialised behaivour. Do
people like these names? Or can someone come up with better names? More
detailed info on the use cases in the JIRA.

Actually, I don't like ExternalizerSpi name, it makes configuration getters
ackward: getExternalizerSpis...

Instead I'm leaning for: Externalizer and AdvancedExternalizer which maps
very nicely with Cache and AdvancedCache and makes getters more readable:
getAdvancedExternalizers much clearer :)

- A related factor here would be to find a better name for the
XML/programmatic configuration, i.e. getServiceProviderExternalizers()?
serviceProviderExternalzer or getExternalizeSpis() externalizerSpi?
This is one thing and the other is that I'd want this XML and programmatic
configuration to be a bit hidden away cos it's specialised or for edge
cases. The obvious route the average Infinispan user should be annotation
and implement Infinispan's Externalizer interface. However, I'm don't
think there's anything special that can be done in the current
architechture of Infinispan without rethinking end user and spi
configuration.

- To hide JBoss Marshaller details away and to simplify some of the API it
provides, I've created a new @MarshallableBy annotation that maps directly
to what JBMAR's @Externalizer does. To get an idea of the differences for
the end users, see
https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e#diff-10
as opposed to
https://github.com/galderz/infinispan/commit/09096f7998c0d0a5aae76d55bf59c72fe1cb510e#diff-9.
Are people happy with the annotation name? The cool thing is that if
someone wants to really use JBoss Marshaller Externalizers, they can, but
I think the majority will be happy with just a read/write object method.