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(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)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@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(a)jboss.org
Telephone: +44 7786 702 706
MSN: manik(a)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@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(a)jboss.org
> Telephone: +44 7786 702 706
> MSN: manik(a)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(a)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
>