Re: Command Recovery

[Klaus Malorny <Klaus.Malorny@knipp.de>]

"Hollenbeck, Scott" wrote:
> 
> >Yes, I do understand this. Nevertheless, to archive the idempotency
> property,
> >you add attributes to the commands that are not necessary. There is no
> >technical requirement to supply a preset ID to the registry for creating a
> new
> >contact. There is no technical requirement to supply the old expiration
> date
> >to renew a domain.
> 
> The contact <create> command requires an ID so that the contact can be
> uniquely identified, much like a domain or host name is used to uniquely
> identify a domain or host.  The ID isn't preset, it's requested at <create>
> time.
> 
> Earlier in this thread we heard about a problem that may arise when contacts
> aren't identified by a unique key.  If you're suggesting that unique
> identifiers/keys aren't needed to identify objects in a database, you've
> lost me.


Sorry, I used the word 'preset' that did not expressed exactly what I meant.
Of course, the client has to specify the ID and there is no default. Unique
keys of course. But here is another small disadvantage: The client has to
select a unique key, whereas it would be much easier for the server to do it
as the server knows all used keys.


> 
> > [...]
> >
> >Can you tell me what they should do in this situation?
> 
> 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?
>

Solution 1 is a more generic approach, while solution 2 is obviously easier to
implement on server side. I discussed this with Thomas and we both think that
we would prefer solution 1.


regards,

Klaus Malorny


___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     Klaus.Malorny@knipp.de             Tel. +49 231 9703 0