[VOTE] Add Store.size() method

[Vadim Gritsenko <va...@verizon.net>]

Let's repeat this with more appropriate subject. My vote is +1: Store
essentially is Collection, and there no collections in Java without
size.

Vadim

> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> 
> People,
> 
> What's your opinion on adding size() method to the Store interface?
> Currently method of getting store size by enumerating through all
store
> items employed in MRUMemoryStore does not fill me with optimism...
> ahem...
> 
> 
> Another - related to this - question: What classes are considered
> "Cocoon public API", the ones which have frozen (since beta)
interface?
> What classes are "Cocoon Internals", where interface could be changed?
> 
> Vadim
> 
> 
> > From: Gerhard Froehlich [mailto:g-froehlich@gmx.de]
> 
> <huge snip>
> 
> > >> Hava you considered a sort of binary approach to emptying stores?
> > >>
> > >> while (MemoryIsLow) {
> > >>      free half of the items in the next store
> > >>      run gc
> > >> }
> > >
> > >I guess half would be too radical :)
> > >May be something like 1/10th (decimal approach) would do the job
> better?
> >
> > Everything no problem *if* the Store interface would have a method
> like
> > <code>int size()</code>. But it doesn't provide this in the moment.
> And we
> > all no how people react, when we change a work interface. But I can
> change
> > the implementation of <code>Enumeration keys()</code> and determine
so
> the
> > size elements in the store. That would be possible.
> >
> > 1/10 I like. Half is a little bit <german>krass</german>. Think
about
> that
> > chain picture Stefano drawed.
> >
> >   Gerhard
> >
> > --------------------------------------------
> > Very funny, Scotty. Now beam down my clothes.
> > ---------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [VOTE] Add Store.size() method

[Berin Loritsch <bl...@apache.org>]

Berin Loritsch wrote:

> Gerhard Froehlich wrote:
> 
>> +1 on this.
>> But for the "normal" FilesystemStore it doesn't make
>> any sense. Should we split the packages?
>> store/persistent
>> store/memory


Just in case you didn't catch it, +1 from me as well.


>>
>> or something else?
> 
> 
> 
> Something else.
> 
> What we are talking about here is the difference between Persistent
> and Transient Storage.
> 
> The Cache implementation is a hybrid (i.e. uses both semantics).
> 
> Therefore both memory and cache would hold to the minimum Store
> interface.  If there is anything to be kept persistently, you would
> extend the Store interface to have a new interface that had that
> guarantee as part of the contract.
> 
> As regards the size() method, we can specify that it will return -1
> if the underlying store does not support that method.
> 
> I think that is the best way in the long run--who knows we may want
> to support it in the future.  Just because we don't need it now, doesn't
> mean we should do development acrobatics to not support it.
> 
> 



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: [VOTE] Add Store.size() method

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Gerhard Froehlich [mailto:g-froehlich@gmx.de]
>
> >As regards the size() method, we can specify that it will return -1
> >if the underlying store does not support that method.

Would prefer if it returned 0. Whatever code uses the store, I can not
think of any reason why it would want to know that the store does not
support the operation. If the store returns 0 instead, then we have one
less special case.

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: [VOTE] Add Store.size() method

[Gerhard Froehlich <g-...@gmx.de>]

Berin,

>From: Berin Loritsch [mailto:bloritsch@apache.org]
>
>Gerhard Froehlich wrote:
>
>> +1 on this.
>> But for the "normal" FilesystemStore it doesn't make
>> any sense. Should we split the packages?
>> store/persistent
>> store/memory
>> 
>> or something else?
>
>
>Something else.

:)

>What we are talking about here is the difference between Persistent
>and Transient Storage.
>
>The Cache implementation is a hybrid (i.e. uses both semantics).
>
>Therefore both memory and cache would hold to the minimum Store
>interface.  If there is anything to be kept persistently, you would
>extend the Store interface to have a new interface that had that
>guarantee as part of the contract.
>
>As regards the size() method, we can specify that it will return -1
>if the underlying store does not support that method.
>
>I think that is the best way in the long run--who knows we may want
>to support it in the future.  Just because we don't need it now, doesn't
>mean we should do development acrobatics to not support it.

Good idea! I cannot think today. I was on a party with
colleagues yesterday and I'm braindead in the moment.

Your proposal would be clean solution and I'm +1 with this!

  Gerhard

---------------------------------
Me, Ambivalent? Well, yes and no.
---------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [VOTE] Add Store.size() method

[Berin Loritsch <bl...@apache.org>]

Gerhard Froehlich wrote:

> +1 on this.
> But for the "normal" FilesystemStore it doesn't make
> any sense. Should we split the packages?
> store/persistent
> store/memory
> 
> or something else?


Something else.

What we are talking about here is the difference between Persistent
and Transient Storage.

The Cache implementation is a hybrid (i.e. uses both semantics).

Therefore both memory and cache would hold to the minimum Store
interface.  If there is anything to be kept persistently, you would
extend the Store interface to have a new interface that had that
guarantee as part of the contract.

As regards the size() method, we can specify that it will return -1
if the underlying store does not support that method.

I think that is the best way in the long run--who knows we may want
to support it in the future.  Just because we don't need it now, doesn't
mean we should do development acrobatics to not support it.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: [VOTE] Add Store.size() method

[Gerhard Froehlich <g-...@gmx.de>]

+1 on this.
But for the "normal" FilesystemStore it doesn't make
any sense. Should we split the packages?
store/persistent
store/memory

or something else?

  Gerhard
 
"Three o'clock is always too late or too early for 
anything you want to do.
(Jean-Paul Sartre)"


>-----Original Message-----
>From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
>Sent: Thursday, January 31, 2002 4:58 PM
>To: cocoon-dev@xml.apache.org
>Subject: [VOTE] Add Store.size() method
>
>
>Let's repeat this with more appropriate subject. My vote is +1: Store
>essentially is Collection, and there no collections in Java without
>size.
>
>Vadim
>
>> From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
>> 
>> People,
>> 
>> What's your opinion on adding size() method to the Store interface?
>> Currently method of getting store size by enumerating through all
>store
>> items employed in MRUMemoryStore does not fill me with optimism...
>> ahem...
>> 
>> 
>> Another - related to this - question: What classes are considered
>> "Cocoon public API", the ones which have frozen (since beta)
>interface?
>> What classes are "Cocoon Internals", where interface could be changed?
>> 
>> Vadim
>> 
>> 
>> > From: Gerhard Froehlich [mailto:g-froehlich@gmx.de]
>> 
>> <huge snip>
>> 
>> > >> Hava you considered a sort of binary approach to emptying stores?
>> > >>
>> > >> while (MemoryIsLow) {
>> > >>      free half of the items in the next store
>> > >>      run gc
>> > >> }
>> > >
>> > >I guess half would be too radical :)
>> > >May be something like 1/10th (decimal approach) would do the job
>> better?
>> >
>> > Everything no problem *if* the Store interface would have a method
>> like
>> > <code>int size()</code>. But it doesn't provide this in the moment.
>> And we
>> > all no how people react, when we change a work interface. But I can
>> change
>> > the implementation of <code>Enumeration keys()</code> and determine
>so
>> the
>> > size elements in the store. That would be possible.
>> >
>> > 1/10 I like. Half is a little bit <german>krass</german>. Think
>about
>> that
>> > chain picture Stefano drawed.
>> >
>> >   Gerhard
>> >
>> > --------------------------------------------
>> > Very funny, Scotty. Now beam down my clothes.
>> > ---------------------------------------------
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org