[jbosscache-dev] Re: Integrating steaming transfer in JBC

[Manik Surtani]

I'm still stabilising HEAD at the moment, almost there.  Once this is  
stable (as far as interfaces go) and we have a properly working test  
suite, you can start moving your stuff in.  I expect to have HEAD  
stable by mid next week.

Cheers,
--
Manik Surtani

Lead, JBoss Cache
JBoss, a division of Red Hat

Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani


On 16 Aug 2006, at 19:23, Vladimir Blagojevic wrote:

> 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
>
> From: Manik Surtani [mailto:manik at jboss.org]
> Sent: Wednesday, August 16, 2006 2:14 PM
> To: Vladimir Blagojevic
> Subject: Re: [jbosscache-dev] Re: Integrating steaming transfer in JBC
>
> 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.
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik at jboss.org
> Telephone: +44 7786 702 706
> MSN: manik at surtani.org
> Yahoo/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
>>
>> From: Manik Surtani [mailto:manik at 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
>>
>> I've got nothing against overloading the methods.
>>
>>
>> --
>> Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>>
>> Email: manik at jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik at surtani.org
>> Yahoo/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 at 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
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20060816/e541b84f/attachment.html