gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm


From: B. Fallenstein
Subject: Re: [Gzz] ``async_storm--benja``: Supporting aynchronicity in Storm
Date: Thu, 28 Nov 2002 13:43:48 +0200

Tuomas Lukka schrieb:
> 
> On Thu, Nov 28, 2002 at 12:34:32PM +0200, B. Fallenstein wrote:
> > > Separate blocking method?
> >
> > I don't like that-- blocking is too unusual to warrant a second method 
> > IMHO. Can
> > you explain why the above is not good?
> 
> Too complicated when just loading the space. 

Hmm: Do note that we don't call this method directly when loading the
space. We call a different method (Filer.load()) that we may also want
to call asynchronously (to load web page slices to swap in). That
seconds my proposal below that the policy to block or not should be
passed through some parameter, not be manifested by having two different
methods... hmmm.

> We want to load at the first from
> local store only.

(I don't like that assumption.)

> > Hmm. What I would like is an easy way to get blocking access, but not 
> > through a
> > separate method; something like passing a special kind of listener, but 
> > don't
> > know how.
> 
> Urgh! Awful.

Well, Listener is probably not the right interface... *still thinking
about what would be*

> I'd really like to be able to know from this side of the API what is local
> and what is not.

Fine with me. Do peg.

> > I definitely need help there, since the problem is not clear to me. Since I
> > cannot make myself clear apparently, I do see that we need such a document, 
> > but I
> > wouldn't know what to write in it...
> 
> I guess this would be the functional requirements for storm.

What does that mean practically?
-b.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]