On Mar 13, 2014, at 12:45, William Burns <mudokonman(a)gmail.com> wrote:
On Thu, Mar 13, 2014 at 8:37 AM, Pedro Ruivo
<pedro(a)infinispan.org> wrote:
>
>
> On 03/13/2014 12:35 PM, William Burns wrote:
>> On Thu, Mar 13, 2014 at 8:31 AM, Pedro Ruivo <pedro(a)infinispan.org> wrote:
>>> Hi,
>>>
>>> #1 and #2 are ok to me but, IMO, the filter package should be in commons
>>> module
>>
>> Sorry I forgot to detail why I said core. I originally planned for
>> commons package as well, however the KeyValueFilter class needs the
>> Metadata class, which doesn't live in the commons package. I didn't
>> want to separate the 2 filter classes. And unfortunately the Metadata
>> class relies on other classes in core, so that isn't easy to move over
>> either, but doable :( WDYT?
>
> can you explain why the metadata is needed? I assumed that the key and
> the value were the only objects needed.
That is how the design doc was written up :P My guess is so that
people if needed can filter out versioned entries or to possibly do
some eviction magic since they can try to calculate when the entry
would be removed. Maybe Mircea can shed some additional light.
org.infinispan.metadata.Metadata was added in order to group all the information that
needs to be associated with a cache entry: timestamp, expiry, idleTime, version but also
custom external data that ISPN extension might want to associate with it: e.g. REST server
associates MIME information:
https://github.com/mmarkus/infinispan/blob/master/server/rest/src/main/sc....
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)