gzz-dev
[Top][All Lists]
Advanced

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

Re: [Gzz] Re: Available overlays PEG


From: Tuomas Lukka
Subject: Re: [Gzz] Re: Available overlays PEG
Date: Mon, 4 Aug 2003 11:00:58 +0300
User-agent: Mutt/1.5.4i

On Mon, Aug 04, 2003 at 09:57:36AM +0300, address@hidden wrote:
> Quoting Tuomas Lukka <address@hidden>:
> 
> > On Sat, Aug 02, 2003 at 11:24:55AM +0200, Benja Fallenstein wrote:
> > > Tuomas Lukka wrote:
> > > >>OpenGL is different because it implements a completely different 
> > > >>interface than AWT offering different capabilities &c. This is more like
> > 
> > > >>deciding in Kaffe which implementation of AWT (X-based? QT-based? 
> > > >>win32-based?) is default.
> > > >
> > > >And tapestry provides DOLR, not DHT. Thus it *is* analogous.
> > > 
> > > We'll use it to implement exactly the same functions as before, which 
> > > includes using a DHT layer built on top of it. If we couldn't do that, 
> > > we probably couldn't use Tapestry.
> > 
> > Ok. But I still see it as a part of architecture -- probably just
> > because we define architecture differently ;)
> 
> 
> Despite Tapestry "implementes" DOLR, 

English correction:

        Even though Tapestry implements the DOLR abstraction,

> Tapestry's API is identical to DHT for
> application. 

Really? Or do you mean that a DHT-like API can be *constructed* 
on top of tapestry? I think tapestry can do more than just DHT.

> For Storm, this process *does* provide key/value operations: for each block 
> in a
> local pool, we could publish blocks ID along additional meta data. Then, when
> looking up storm blocks, we starts query with a block ID and wait Tapestry to
> finish the lookup process (and of course, we don't need hash data anymore 
> since
> Storm has done it already). Therefore, I still see that we could use Tapestry.

Yes, I do think it is possible as well.

        Tuomas




reply via email to

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