Re: [Gzz] Re: Available overlays PEG

[hemppah]

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, Tapestry's API is identical to DHT for
application. For example, with Tapestry 2.0, there comes a file sharing
application (Interweave) similar to Kazaa. Specifically,
tapestry2/src/ostore/tapestry/interweave/Interweave.java (a Interweave peer)
performs key/value (i.e. lookup/retrieval) operations as follows,

1) By publishing local shared directory's meta data, i.e., file names, last
modified date, file size, data type and keyword using SHA-1 hashing function.

2) For each SHA-1 produced key, Tapestry routes the (key, publisher) touple to
the closest peer (root peer) in a network with a publishing path.

3) To search a data, say based on a filename, Interweave peer hashes a filename
and starts looking a value for the key: in each hop, Tapestry comes closer to
the closest peer (root) in a network. Once the root peer is found, it returns a
pointer to the search originator and retrieves the file from the original 
publisher.

(Isn't this quite close to key-value operation, right? ;))

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.

I *strongly* recommend reading the this paper for more detailed information
about Tapestry's routing &c (especially page 4):
http://www.cs.berkeley.edu/~ravenben/publications/pdf/tapestry_jsac.pdf



-Hermanni

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/