Am 25.04.11 11:09, schrieb "이희승 (Trustin Lee)":
> What do you think about my idea posted at JIRA? - http://j.mp/faeyh6
See here:
https://issues.jboss.org/browse/ISPN-78?focusedCommentId=12597763&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12597763
Olaf
>
> On Fri
What do you think about my idea posted at JIRA? - http://j.mp/faeyh6
On Fri 22 Apr 2011 05:56:31 PM KST, Manik Surtani wrote:
> On 21 Apr 2011, at 21:02, Olaf Bergner wrote:
>
>> Am 20.04.11 00:35, schrieb Mircea Markus:
>>> On 19 Apr 2011, at 18:17, Olaf Bergner wrote:
>>>
Am 19.04.11 16:
On 21 Apr 2011, at 21:02, Olaf Bergner wrote:
> Am 20.04.11 00:35, schrieb Mircea Markus:
>> On 19 Apr 2011, at 18:17, Olaf Bergner wrote:
>>
>>> Am 19.04.11 16:59, schrieb Mircea Markus:
>>> I personally favor a separate dedicated interface, e.g. StreamingCache
>>> as has been suggested, and ma
Am 20.04.11 00:35, schrieb Mircea Markus:
> On 19 Apr 2011, at 18:17, Olaf Bergner wrote:
>
>> Am 19.04.11 16:59, schrieb Mircea Markus:
>> I personally favor a separate dedicated interface, e.g. StreamingCache
>> as has been suggested, and maybe a method getStreamingCache() on Cache.
> yes, that
On 19 Apr 2011, at 18:17, Olaf Bergner wrote:
> Am 19.04.11 16:59, schrieb Mircea Markus:
>> On 19 Apr 2011, at 10:06, Galder Zamarreño wrote:
>> So I presume you are building this as a separate Maven module, and making
>> use of the module-specific commands as described here [1] and [2] ?
>>> W
Am 19.04.11 16:59, schrieb Mircea Markus:
> On 19 Apr 2011, at 10:06, Galder Zamarreño wrote:
> So I presume you are building this as a separate Maven module, and making use
> of the module-specific commands as described here [1] and [2] ?
>> Why would he need a separate module? He's not bringing
On 19 Apr 2011, at 10:06, Galder Zamarreño wrote:
>
> On Apr 18, 2011, at 12:35 PM, Manik Surtani wrote:
>
>>
>> On 15 Apr 2011, at 18:00, Olaf Bergner wrote:
>>
>>> Am 15.04.11 16:56, schrieb Manik Surtani:
On 11 Apr 2011, at 13:13, Galder Zamarreño wrote:
> - Rather than modi
On 19 Apr 2011, at 12:05, Olaf Bergner wrote:
> As to locking I currently think that locking metadata will probably suffice.
> Right now I started thinking about how to eventually implement transactions.
> Currently a transactions accumulated state is retained until it is finally
> prepared/co
Original-Nachricht
> Datum: Tue, 19 Apr 2011 11:06:50 +0200
> Von: "Galder Zamarreño"
> An: infinispan -Dev List
> Betreff: Re: [infinispan-dev] [ISPN-78] Feedback needed
>
> On Apr 18, 2011, at 12:35 PM, Manik Surtani wrote:
>
> >
On Apr 18, 2011, at 12:35 PM, Manik Surtani wrote:
>
> On 15 Apr 2011, at 18:00, Olaf Bergner wrote:
>
>> Am 15.04.11 16:56, schrieb Manik Surtani:
>>> On 11 Apr 2011, at 13:13, Galder Zamarreño wrote:
>>>
- Rather than modifying PutKeyValueCommand, it might be better to subclass
it
On 15 Apr 2011, at 18:00, Olaf Bergner wrote:
> Am 15.04.11 16:56, schrieb Manik Surtani:
>> On 11 Apr 2011, at 13:13, Galder Zamarreño wrote:
>>
>>> - Rather than modifying PutKeyValueCommand, it might be better to subclass
>>> it and add the large object logic there? i.e. PutLargeKeyValueComm
On 15 Apr 2011, at 17:56, Olaf Bergner wrote:
> Am 15.04.11 16:59, schrieb Manik Surtani:
>> On 13 Apr 2011, at 19:26, Mircea Markus wrote:
>>
>>> IMO the large object methods would fit better in the Cache directly, vs
>>> AdvancedCache.
>> Perhaps a new interface? StreamingCache?
> I do like
On 15 Apr 2011, at 17:53, Olaf Bergner wrote:
> Am 15.04.11 17:01, schrieb Manik Surtani:
>> On 10 Apr 2011, at 21:07, Olaf Bergner wrote:
>>
>>> Keep in mind that so far I have completely ignored the issue of
>>> supporting transactions when reading and writing large objects. I would
>>> prefer
Am 15.04.11 16:56, schrieb Manik Surtani:
> On 11 Apr 2011, at 13:13, Galder Zamarreño wrote:
>
>> - Rather than modifying PutKeyValueCommand, it might be better to subclass
>> it and add the large object logic there? i.e. PutLargeKeyValueCommand - I'd
>> also suggest adding a new build* method i
Am 15.04.11 16:59, schrieb Manik Surtani:
> On 13 Apr 2011, at 19:26, Mircea Markus wrote:
>
>> IMO the large object methods would fit better in the Cache directly, vs
>> AdvancedCache.
> Perhaps a new interface? StreamingCache?
I do like this approach. It keeps closely related methods in one pla
Am 15.04.11 17:01, schrieb Manik Surtani:
> On 10 Apr 2011, at 21:07, Olaf Bergner wrote:
>
>> Keep in mind that so far I have completely ignored the issue of
>> supporting transactions when reading and writing large objects. I would
>> prefer to have a working core implementation before tackling t
On 10 Apr 2011, at 21:07, Olaf Bergner wrote:
> Keep in mind that so far I have completely ignored the issue of
> supporting transactions when reading and writing large objects. I would
> prefer to have a working core implementation before tackling the more
> complicated aspects.
How do you
On 13 Apr 2011, at 19:26, Mircea Markus wrote:
> IMO the large object methods would fit better in the Cache directly, vs
> AdvancedCache.
Perhaps a new interface? StreamingCache?
> The way I see it AdvancedCache exposes to the power user internal ISPN stuff
> - stuff that's not generally nee
On 11 Apr 2011, at 13:13, Galder Zamarreño wrote:
> - Rather than modifying PutKeyValueCommand, it might be better to subclass it
> and add the large object logic there? i.e. PutLargeKeyValueCommand - I'd also
> suggest adding a new build* method in the command factory...etc. This keeps
> the
IMO the large object methods would fit better in the Cache directly, vs
AdvancedCache.
The way I see it AdvancedCache exposes to the power user internal ISPN stuff -
stuff that's not generally needed by every day user. E.g. the interceptor
chain, the rpc manager etc.
Everything that is plain API
Really nice stuff!
On 11 Apr 2011, at 13:13, Galder Zamarreño wrote:
> Hey Olaf,
>
> First of all, thanks for work put so far on this!
>
> Pity you could not make it last week to Berlin Expert Days. I would have been
> great to sit down and go through this code together :| - hope you're doing
Hi Galder,
Am 11.04.11 14:13, schrieb Galder Zamarreño:
> Hey Olaf,
>
> First of all, thanks for work put so far on this!
>
> Pity you could not make it last week to Berlin Expert Days. I would have been
> great to sit down and go through this code together :| - hope you're doing
> better health
Hey Olaf,
First of all, thanks for work put so far on this!
Pity you could not make it last week to Berlin Expert Days. I would have been
great to sit down and go through this code together :| - hope you're doing
better health wise :)
Here are my thoughts so far:
- First of all, since you ha
I have the skeleton of an implementation of ISPN-78 - Large Object
Support - at https://github.com/obergner/infinispan/tree/t_ispn78.
Before going forward I could need some feedback on whether my approach
makes sense at all, what alternatives there are, where things might be
improved or modifie
24 matches
Mail list logo
