Re: Is State-based LDUP needed?

Ed,

First, I'll say that we've only been looking at log-based implementations 
- probably because we see benefits in doing this way.

Second, it occurs to me that LDUP really doesn't need to have two 
interoperable "state-based" implementations - it just needs to have two 
interoperable implementations (regardless of state-based/log-based). Thus, 
I don't quite follow your argument that we'd need at least two state-based 
implementations to leave "state-based" references in the specs.  If/when 
we get two interoperable implementations (state-based or log-based), that 
would be enough I would think.

Either way though, if just concentrating on "log-based" moves the specs 
along quicker, I'm all for it.

Regards,
Tim Hahn

Internet: [email protected]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681





"Ed Reed" <[email protected]>
Sent by: [email protected]
12/13/2001 11:05 PM

 
        To:     <[email protected]>
        cc: 
        Subject:        Is State-based LDUP needed?

 


I asked this question at the ldup meeting on Thursday, and agreed to post 
the question to the distribution list.

Is anyone planning to implement state-based ldup?  If not - that is, if 
there are not going to be at least two interoperable implementations of 
the proposed specification, should we not remove it from the ldup design 
now, rather than later?

The protocol will support it, but there are certainly places in the 
architecture and other documents where the different handling of change 
information required by the state-based scheme adds unnecessary text if 
noone is actually going to use it.

This is a pragmatic decision - I personally like state based schemes, even 
though there are things (like transaction replication) that I doubt 
they'll ever be able to handle well.  Also, all the implementers I know 
are focused on the log-based scheme, instead.  It seems easier for them to 
get their heads around, for some reason...

So - I don't think it's appropriate for me to be the only one championing 
it, and have reached the conclusion that if we can't find even two 
implementers to build it, we should not bother including it in further 
work.

If you're planning to build it, speak up.  If not, silence may well be 
taken as assent to remove references to it from the various protocol 
documents.

Best regards,
Ed

Ps - yeah, I know, you told me so...

=================
Ed Reed
Reed-Matthews, Inc.
+1 585 624 2402
http://www.Reed-Matthews.COM
Note:  Area code is 585