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

[b . fallenstein]

> > Hmm. Ok. First I was a bit worried about cases where we want blocking 
> > access (e.g. during startup, when we're waiting for the first pointer to
> 
> > be resolved and really cannot do anything else)-- but in these cases, we
> 
> > can write:
> > 
> > listener = BlockingJobListener()
> > while(true) {
> > block = pool.get(id, listener);
> > if(block != null) break;
> > block.wait();
> > }
> 
> Ouch... that's not good. getSYNC()?

?
 
> > a) finished() is not specific to blocks: For most lookups, we want to be
> 
> > able to know when they're finished (e.g. pool.getIds()).
> 
> Shouldn't pool.getIds() block?

Why? It's a best-effort method anyway.

> > b) Listeners should not be abstract classes, since some people like to 
> > implement them as mix-ins.
> 
> Java has local classes so this is not necessarily a good thing.
> Mix-ins are usually used to get some *code*, which is impossible in Java.

Hey, that's not a reason to be inconsistent! In Java, there is the strong
convention that Listeners are interfaces, and breaking conventions is always
bad (except if there's a really big gain, but that's not the case here).

> > c) I think timeout() and finished() will usually be implemented the same
> 
> > way, so why have two different methods?
> 
> Really? For timeout() I'd usually do nothing, for finished, a redraw.

When loading blocks maybe, but e.g. for pointers, if I don't know whether I
have complete data I still need to go on somehow...

> > We could have a JobListener and a JobCompletionListener, with the former
> 
> > inheriting the latter, if you prefer (because for blocks, 
> > newDataAvailable() won't be called).
> 
> That might be.

Ok.
- Benja