gzz-commits
[Top][All Lists]
Advanced

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

Re: [Gzz-commits] manuscripts/storm article.rst


From: hemppah
Subject: Re: [Gzz-commits] manuscripts/storm article.rst
Date: Wed, 22 Jan 2003 15:04:22 +0200
User-agent: Internet Messaging Program (IMP) 3.1

Quoting Benja Fallenstein <address@hidden>:

> address@hidden wrote:
> > Quoting Benja Fallenstein <address@hidden>:
> > 
> > 
> >>>>So the point of replication is that two systems always contain the same
> 
> >>>>information, although there may be problems with this if conflicting 
> >>>>updates have been made to the two systems (presumably used by different
> 
> >>>>people). As I said, we want more things than that.
> >>>
> >>>
> >>>Yes, partly true. Replication can happen between more than two systems
> >>
> >>(e.g. in
> >>
> >>>Notes) and the conflicting is a 'feature' of replication of the system
> >>>(implementation issue as in Notes ;). Furthermore, term 'replication' is
> >>
> >>widely
> >>
> >>>used also in p2p research community, so it's not tied only to server
> >>
> >>architectures.
> >>
> >>It's used in a *completely different sense*, which is precisely one 
> >>reason why I'm so opposed to it. Replication in the p2p community means 
> >>mirroring for stability/accountability.
> > 
> > 
> > Hm, in what way *completely different sense* ? 
> 
> In p2p, all replicas of a piece of data store exactly the same data 
> (replication is for performance).

Data availability/dependability is the most important reason for data
replication in p2p. In p2p, performance follows since the probability of finding
is higher as the number of copies of identical data increases.

> 
>  > As far as I have understood, the
> > arcitecture is different to our case (client-server, p2p), but the goal
> remains
> > the same; merge different versions of data, where data can reside in
> > different locations,
> 
> No. P2P replicas are never intended to store different versions of data.


Indeed, but I didn't mean this. I meant that despite of architecture, by
replicating data, we have the same *goal*: we can achieve identical data, even
if there are many users in different locations. The applicability of the
architecture is an another story ;).


> 
> > so that we all have exact/identical copies of data.
> 
> Identical copies of data is a goal of p2p replicas (which is *not* 
> archieved by merging versions in any system I know-- you cannot make a 
> modification to a single replica, making a modification means updating 
> *all* replicas, since they are supposed to be perfect copies, so there 
> *can not* be versions to be merged on different replicas!). Identical 
> copies of data are often not a goal in Storm.

For p2p replicas, I absolutely agree.

In this case, what are the goals of Storm ?


> 
> > For p2p, indeed. I think term 'replication' is somehow misused.
> 
> I do not think so. I think the use in p2p is dead on :)

Read: in p2p field, term 'replication' is misused. I didn't mean 'in general,
term replication...'.

So we both agree this ;).

> 
>  > But, my point
> > was that term 'replication' is *not only used* in client-server
> environment.> 
> And my point was that only the use in a client-server environment comes 
> even close to what we want with Storm.
>  
> > To be serious, term 'sync*' has a strong relationship to *time*, which on
> the
> > other hand, is not what we are interested in: "Now, because it's noon, we
> should
> > synchronize our all blocks, since our meeting starts in one hour". 
> 
> I do not believe that the word sync, as used in the PDA field, is 

At this point, aren't we more close to client-server field than to PDA field ? 
;)

> related to time as much. I do believe that the term 'replica' is 
> strongly related to 'aim for always identical data,' which does not 

Not *always*. Only then, when we want the data is identical/up to date, or when
we think that data is 'out of sync'.

> convey the correct image about Storm. I do agree that 'sync' may not be 
> the best term, but for the same reason that I don't like 'replica,' just 
> weaker-- 'sync,' too, conveys the image that we aim to keep the same 
> data everywhere. I think it's the better term because it at least allows 
> the idea that data may be 'out of sync.' Replica, by the very word, 
> suggests that the data is always the same on all devices.

I think you are now messing up with apples and oranges ;).

As said, replica is a *instance of same data*, and therefore, there can be very
different version of other replicas in the system, for example, after user has
made modifications to a specific replica.

Replication doesn't mean that data is 'everywhere in all devices'. It's a *way*
for merging different versions of the same data. In Notes, for example, a mobile
client may be 'out of sync', if client hasn't *replicated* with others for a
while. When a mobile client performs a *replication*, modifications will be
merged to both locations, into mobile clients data repository and also into the
others' data repository.

So, data may be 'out of sync', if *replication* hasn't been performed.


­-Hermanni

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




reply via email to

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