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

[Tuomas Lukka]

On Fri, Nov 08, 2002 at 07:00:34PM +0100, Benja Fallenstein wrote:
> Tuomas Lukka wrote:
> 
> >On Fri, Nov 08, 2002 at 02:39:08PM +0100, Benja Fallenstein wrote:
> > 
> >
> >>Sorry, but for "get this some time in the future" for now don't see any 
> >>use case at all. 
> >>   
> >>
> >
> >Let's say I have a *lot* of blocks on my hard drive and I'm on the train.
> >I start reading some stuff I haven't read before.
> >
> >At that point, my system would make note of getting the related stuff
> >at some point.
> >
> 
> 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.

> As for what you describe: It seems to me that this is related to what 
> the InterPlaNet research group (at IETF) is working on: 
> store-and-forward protocols. If you're interested in that kind of thing, 
> it would make sense to look at their stuff.

No time for some time, unfortunately. Hemppah?

> >>The interface I have in mind is like the spaces': 
> >>get(id, obs) returns a block if we currently have it, otherwise null; if 
> >>we don't have it we request it from the network, and if we can find it 
> >>there, we fire the Obs so that the views will get refreshed. 
> >>   
> >>
> >
> >Ah, we're thinking about different time spans. The views will be refreshed
> >every minute or so anyway.
> >
> 
> 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.

        Tuomas