Ok np. My current task is to integrate streaming state transfer into JBC and I will be working mostly under Brian's guidance. What is the deadline for this integration and how do we proceed?Vladimir
Correct. At the end of the day this is just an overload on the same functionality, allowing different approaches, so we're not really making the interface any more complex.
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Wednesday, August 16, 2006 2:14 PM
To: Vladimir Blagojevic
Subject: Re: [jbosscache-dev] Re: Integrating steaming transfer in JBC
--Manik SurtaniLead, JBoss CacheJBoss, a division of Red HatEmail: manik@jboss.orgTelephone: +44 7786 702 706MSN: manik@surtani.orgYahoo/AIM/Skype: maniksurtani
On 16 Aug 2006, at 15:08, Vladimir Blagojevic wrote:
Manik,You mean you have nothing against 8 method approach for state transfer?Vladimir
I've got nothing against overloading the methods.
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Wednesday, August 16, 2006 5:28 AM
To: Bela Ban
Cc: Vladimir Blagojevic; Ben Wang; Brian Stansberry
Subject: Re: [jbosscache-dev] Re: Integrating steaming transfer in JBC
--Manik SurtaniLead, JBoss CacheJBoss, a division of Red HatEmail: manik@jboss.orgTelephone: +44 7786 702 706MSN: manik@surtani.orgYahoo/AIM/Skype: maniksurtani
On 16 Aug 2006, at 07:36, Bela Ban wrote:
So you;re saying, since the methods that take a byte[] will construct an input stream anyway, why not provide the stream in the first place ? I like the idea; and it should not be hard to write code that generates a byte[] array from an input stream. However, what's wrong with having 8 state transfer methods, and provide a ListenerAdapter class, which has null implementations, and you simply extend that adapter class ?
Vladimir Blagojevic wrote:Guys, Is there a need to have additional 4 methods (thus in total 8 methods for state transfer) in CacheLoader API in order to support both streaming and byte based state transfer or can we cover both types of state transfer by having only 4 InputStream/OutputStream based methods? These 4 methods would be something like: void storeEntireState(InputStream s); void storeState(Fqn subtree,InputStream s); void loadEntireState(OutputStream s); void loadState(Fqn subtree,OutputStream s); We ensure that byte state transfer is still supported but that doesn't mean the CacheLoader needs to take/return byte[]! If byte state transfer is used, the StateTransferIntegrator can be responsible for creating ByteArrayInput(Output)Stream from the persistent state byte[] and pass stream to the CacheLoader instead of byte[]. There will still be complexity in the integrator code to support both flavors, but that complexity doesn't need to be pushed from jgroups layer all the way through to the CacheLoader API. Thoughts? _______________________________________________ jbosscache-dev mailing list jbosscache-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev-- Bela Ban Lead JGroups / Manager JBoss Clustering Group JBoss - a division of Red Hat