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

[Tuomas Lukka]

> 
> >>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 didn't mean that literally - just that I'd prefer a global point.

> 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. 

I think that for Storm, that might make a *lot* of sense.

> 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).

The problem with Obses is that you always forget to put in a couple.
That's why I don't actually really like them and would prefer a more
abstract approach, being able to say

        "Call foo() and tell me when calling it would do a different thing".

where foo() would be just about any function.

Unfortunately Java can't quite handle that.

        Tuomas