Re: [Gzz-commits] gzz ./TODO doc/gzz.css doc/pegboard/.cvsignore ...

[Benja Fallenstein]

Tuomas Lukka wrote:

> On Fri, Nov 08, 2002 at 07:00:34PM +0100, Benja Fallenstein wrote:
>  
>
> > Ok, let me clarify: Use case *for now*. I want to peg something that 
> > makes sense to implement as a demo *now*. What you describe is part of 
> > the "full vision"-- but I don't feel we need to write interfaces for 
> > that now (except if you're keen on making a demo of it now, but I don't 
> > think it's so important). My point is that some kind of asynchronizity 
> > is necessary to make any use of Storm on the network at all-- what you 
> > describe is interesting, but not vital for getting us running.
> >    
>
> Yes, agreed. But it's good to put in as a note to say where we are going
> with this.

Ok, will do.

> > Yes. However, that's like building a browser and saying, "well, if we 
> > have loaded an image, we can show it when we refresh the view next time; 
> > the user will scroll every minute or so anyway, then we just put the 
> > image in." If you used such a browser, when you're waiting for an image 
> > you would scroll up and down and up and down... until the image appears. 
> > Argh! That's not something I'd like to either use or present in a demo ;-)
> >    
>
> No, the point's more that for something like these we could just make
> a call to abstractUpdateManager of something having been changed.

I don't like that, because Storm should be independent of the update 
manager etc. I was figuring the Obs would call 
AbstractUpdateManager.chg(). But we could also have a more Javaesque 
SomethingListener that would generate events when the blocks arrive. In 
any case, it would wind up as passing something else to Storm that would 
then call AUM.chg(). I like Obs because that's more general in our view 
structure (e.g., if we've cached the contents of one window, we can pass 
the Obs for refreshing that cache to Storm; AUM.chg() will not refresh 
but re-use the cached version).

- Benja