Subject: Re: No partial success when it comes to deletion?

From: Andrea Campi <[email-masked]>
Date: Fri, 31 Jan 2003 09:28:49 +0100

Now, before I get carried away again: if the consensus is to have
no transactions for now, I'm fine. See the answer to Doug (which I'll send
in a minute).
If you are still interested, read through ;-)

On Thu, Jan 30, 2003 at 04:38:08PM -0500, [email-masked] wrote:
> All of the DELETEs worked except the one for UID:0987654321 in TARGET:work 
> which failed with a REQUEST-STATUS:4.0. (made up value for demonstation 
> purposes only).  Why should the previously successful DELETEs be undeleted 
> because of an unrelated failure??  It makes no sense to me.

OK.

> > parses everything. There are so many ways of doing the same thing!
> 
> If ordering by TARGET is important to you then Id say that concurrent 
> DELETEs on separate channels is the way you would probably want to go.  Or 
> am I missing the root of the concern here?

It's not that which is worrying me, it's a matter of simplicity,
consistency and regression tests to cover all possible cases. If one
implementor gets one of the many cases wrong, we end up facing
hard times...

> > Anyway, back to the discussion. You still assume it IS meaningful
> > to assume commands are not atomic; I contend that the CS simply
> > has no way of knowing. Compare the following:
> 
> Not quite.  I think that atomicity of the command varys with the command. 
> For example, a DELETE of a VEVENT in 1 VAGENDA succeeds and a positive 
> VREPLY is sent back.  Then the attempted deletion of a different VEVENT 
> fails.  Why should this make the first success now a failure??

That's what I say: the CS has no way of kowing, the CUA has some more
hints.

> A MOVE is slightly different in that it involves essentially a CREATE and 
> then a DELETE and both must succeed for a single success VREPLY to be 
> sent.  Again though the command scopped to the effected component, NOT to 
> the TARGET or the entire command.

Agreed.

> > I can agree #1 doesn't need to be atomic - if I get any failure
> > I can simply retry.
> 
> Thats a start toward full agreement... ;^)

Yes.

> > In case #2, I would actually love to be able to perform both CREATE
> > as a single atomic transaction. Unfortunately, there's no way I
> > can do that.
> 
> Nope.  The act of creating the 2 entries on your calendar should happen 
> first.  Otherwise you've sent out invitations to something that isn't on 
> your calendar and thus any responses you get back from the invitees wont 

Yes you're right, ok. But this doesn't change the main problem. See below.

> Yeah, so?  The 1st and 2nd VAGENDAs allow you write permission so you can 
> CREATE the invitation.  The 3rd does not (what a weenie for not wanting me 
> to access their calendar!).  So does that mean that you were unable to 
> invite the first 2 people?  Certainly not.  Does that mean the entire 
> CREATE command should be failed?  Nope.

You could argue that and you would be correct. At the same time my HR
manager who just wanted to book the meeting with the 3 guys would arguee
that he wanted to meet all 3 of them, not 2, so the computer failed;
and he'd be correct as well. :-P

Now seriously: if the CUA gets back the error, it must take corrective
actions. As a minimum it should change the VEVENT to show that the
invitation failed (how?). Surely it should ask the CU what to do now.
However, the CU might be leaving just now etc so the CUA should probably
also update the VEVENT on the organizer VAGENDA. Also, as Doug mentioned,
there could be a bot on one of the attendees VAGENDA which could act
immediately on it etc.

So no matter how you look at it, creating an event IS a transaction -
we just get to pick whether it's implemented on the server or on the
client.

It would be different if we had ways of avoiding most problems (apart
from exceptional, transient ones) - for instance, a CUA could first
of all verify that all TARGETs exist, ask the CS if it has access
to them etc. So that it could inform the CU even BEFORE she pressed
the Ok button. In that case, failure would be really an exception.
But as things stand, even something as simple as a mistyped URI could
cause a sequence of CAP commands, failure, phone calls ("look, I'm
trying to accept your meeting proposal, but this darn program keeps
giving me an error message!") etc. How do you handle all this?

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy