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


To: ietf-provreg@cafax.se
From: Daniel Manley <dmanley@tucows.com>
Date: Wed, 19 Sep 2001 11:30:39 -0400
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
Subject: Re: Command Recovery

>
>
>
>Ahh, OK, I see your point here.  I see two ways we might be able to address
>the issue:
>
>1. Add a status command that checks to see if a particular client-provided
>transaction identifier has been logged as part of a successful command.
>With client TRIDs being OPTIONAL [1] this won't work if the client doesn't
>provide a TRID, but it can help if they do.  Or,
>
>2. Add client TRID information to the <info> response for an object.  If we
>log the TRID of the last write operation (if one is provided), clients can
>do an <info> command, look at the client TRID, see if it's one they
>recognize, and react accordingly.
>
>Is one preferable over the other?  I kind of like the second option because
>it fits into what's documented right now.  Does anyone else have an opinion?
>
Option 1 would mean creating a transaction object and an info or check 
command for it?  Certainly option 1 holds more historical information. 
 But option 2 would be easier to implement...

I guess option 1 seems like the most versatile and useful, so my 
preference is with 1.  Could client trids still be optional if you went 
ahead with number 1?  Does it even make sense to keep them optional in 
that case?

Dan



Home | Date list | Subject list