Re: [infinispan-dev] Dynamic Externalizers sorted for ISPN-986 - looking for some feedback
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) > > - A related factor here would be to find a better name for the > XML/programmatic configuration, i.e. getServiceProviderExternalizers()? > or getExternalizeSpis() ? 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 - 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
Re: [infinispan-dev] Dynamic Externalizers sorted for ISPN-986 - looking for some feedback
On 11-04-01 11:54 AM, 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 say forget disrupting little code as possible as a guideline, lets integrate a solution with these automatically installed Externalizers that you mention in the JIRA. I bet you most users will love and only need that. OTOH current mechanism should stay in place for both SPIs and regular super users willing to put an effort and squeeze out every bit of performance. ___ 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
On Apr 11, 2011, at 3:04 PM, Vladimir Blagojevic wrote: > On 11-04-01 11:54 AM, 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 say forget disrupting little code as possible as a guideline, lets > integrate a solution with these automatically installed Externalizers > that you mention in the JIRA. I bet you most users will love and only > need that. OTOH current mechanism should stay in place for both SPIs and > regular super users willing to put an effort and squeeze out every bit > of performance. Well, this is not disrupting much cos all this functionality is new stuff in Infinispan 5.0, so nothing's set in stone yet :) > ___ > 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
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()? >> or getExternalizeSpis() ? 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 - > 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
+1 for Externalizer/AdvancedExternalizer. Dan On Tue, Apr 12, 2011 at 10:17 AM, Galder Zamarreño 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()? >>> or getExternalizeSpis() ? >>> 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 - >> 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 > ___ 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
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 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()? or getExternalizeSpis() ? 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 - >>> 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 >> > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing lis
Re: [infinispan-dev] Dynamic Externalizers sorted for ISPN-986 - looking for some feedback
Yeah, eventually those were the names that made most sense to me. FYI, the pull req for this is up now: https://github.com/infinispan/infinispan/pull/245 I'm now working on updating http://community.jboss.org/docs/DOC-16198 On Apr 12, 2011, at 6:41 PM, Mircea Markus wrote: > 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 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()? > or getExternalizeSpis() ? > 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 - 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 >>> >>> >>> __
