Subject: Question

From: Andrea Campi <[email-masked]>
Date: Thu, 1 Aug 2002 18:41:43 +0200

Hi all,

I'm reading section 2.2 and I need confirmation I'm reading this
correctly. This might also be a hint that this might be stated in
a more explicit way...

[...]
If existing "UNPROCESSED" objects exist in the CS for the same UID then a CUA may wish to consolidate the objects in to one "BOOKED" object. The CUA would fetch the "UNPROCESSED" objects for that UID and process them in the CUA as described in [iTIP]. Then if the CUA wished to book the UID, then the CUA would issue a "CREATE" command to create the new "BOOKED" object in the CS, followed by a "DELETE" command to remove any related old [iTIP] objects from the CS. And it might also involve having the CUA send some [iMIP] objects or contacting other CS's and performing CAP operations on those CSs. 
[...]
 Several "UNPROCESSED" entries can be in the CS for the same UID. However once consolidated, then only one entry exists in the CS and that is the booked object. The others MUST BE removed, or have their state changed to "DELETED".

There MUST NOT BE more than one "BOOKED" entry in a calendar for the same "UID". 

So I should first CREATE the BOOKED object and then delete the
UNPROCESSED ones, ok.
What puzzles me is the statement that "others MUST BE removed": how
can a server possibly enforce this? This is in fact saying that BOOKED
and UNPROCESSED entries MAY exist at the same time, however short
that can be.

By the way, this would be solved by doing it the other way around
(first delete then create) IFF we had some way of doing atomic
transactions...

Bye,
	Andrea

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

---

From: John Stracke <[email-masked]>
Date: Fri, 02 Aug 2002 14:44:55 -0400

Andrea Campi wrote:

>can a server possibly enforce this?
>  
>
By deleting the UNPROCESSED ones once the BOOKED one has been created, 
without waiting for the client to tell it to.

-- 
/===========================================================\
|John Stracke      [email-masked]                  |
|Principal Engineer|http://www.centivinc.com                |
|Centiv            |My opinions are my own.                 |
|===========================================================|
|Stupid, adj.: Losing $25 on the game and $50 on the instant|
|replay.                                                    |
\===========================================================/

---

From: Doug Royer <[email-masked]>
Date: Fri, 02 Aug 2002 13:30:10 -0600

> without waiting for the client to tell it to.

I really had not thought of having the CS do it, we could.

Do we want to make the CS delete all unprocessed entries
for the same UID when a UID is booked? The the CS could
do its best to transaction lock (as you point out below).

> This is in fact saying that BOOKED

You can have booked and UNPROCESSED entries for the same UID
in the CS. I meant to say that the CUA should do the removal
once the unprocessed entries are processed.

Are there any down sides to having the CS do the removal
automatically?

> (first delete then create) IFF we had some way of doing atomic

Yes. And if we did require the CS to do that (removal), then for
implementations that have transaction enabled databases
behind them - it would work safer.

---

From: John Stracke <[email-masked]>
Date: Fri, 02 Aug 2002 15:47:43 -0400

>behind them - it would work safer.
Right.  And, for those that don't, it can't be made safer (unless they 
want to implement transactions themselves, which, ah, will give them 
some time-to-market problems ;-).

It might be clearer to add a new command to consolidate the entries, 
rather than having a DELETE happen as a side effect of CREATE.  In that 
case, we'd add the restriction that CREATing a BOOKED entry will fail if 
there's an UNPROCESSED entry with the same UID.

Alternatively, what are the implications of requiring the CUA to cope 
with BOOKED and UNPROCESSED existing together? That might be better--by 
removing a restriction on the CS, it'd promote scalability.

---

From: Andrea Campi <[email-masked]>
Date: Fri, 2 Aug 2002 22:29:36 +0200

> some time-to-market problems ;-).

Well, it wouldn't be hard to support an atomic command to do this. You 
just need to make sure you don't delete UNPROCESSED entries which might 
arrive while you are deleting them - I can think of at least 2 ways to 
do this [*].

> case, we'd add the restriction that CREATing a BOOKED entry will fail 
> if there's an UNPROCESSED entry with the same UID.

I was about to agree with Doug (having the server delete the UNPROCESSED 
entries), but you do have a point here.
I guess it would be better if we had a command to consolidates entries. 
A server might not implement it; in that case, the client should 
fallback to deleting the entries by itself, and take the hint that it 
might not be safe to do that.

> removing a restriction on the CS, it'd promote scalability.

That was the initial question, in the current draft I don't see any such 
requirement.

Bye,
	Andrea

[*] 1- some kind of serialization point;
      2- holding a reference to the storage entries and delete them, 
without reloading the list.

---

From: John Stracke <[email-masked]>
Date: Fri, 02 Aug 2002 16:31:23 -0400

Andrea Campi wrote:

> I guess it would be better if we had a command to consolidates 
> entries. A server might not implement it;

Very bad idea--that would mean every client has to have code to do it 
both ways.

However, a server might not implement it *atomically*.

-- 
/=============================================================\
|John Stracke      [email-masked]                    |
|Principal Engineer|http://www.centivinc.com                  |
|Centiv            |My opinions are my own.                   |
|=============================================================|
|Q: What goes "Pieces of 7! Pieces of 7!"? A: A parroty error.|
\=============================================================/

---

From: Andrea Campi <[email-masked]>
Date: Fri, 2 Aug 2002 23:24:02 +0200

> Very bad idea--that would mean every client has to have code to do it 

True..

> However, a server might not implement it *atomically*.

I'm not sure what's worse, really. I'd really like to be able to trust 
the server to not lose data.

I think we should at the very least warmly recommend a server SHOULD do 
its best to do it amotically. I also think we should have a capability 
to specify if the server has real transactions or not.

Also, while we're speaking of this, today a thought struck me. Suppose 
I'm setting up a meeting with other people on the same server:

BEGIN:VCALENDAR
PRODID:A CUA
METHOD:REQUEST
TARGET:my-agenda
TARGET:att1-agenda
TARGET:att2-agenda
BEGIN:VEVENT
...
ORGANIZER:[email-masked]
ATTENDEE:[email-masked]
ATTENDEE:[email-masked]
ATTENDEE:[email-masked]
END:VEVENT
END:VCALENDAR

Question: should I include my agenda in the TARGETs and immediately 
change it to BOOKED? Or should I only include TARGETs for other people 
and immediately create a BOOKED entry on mine?
Either way, I need to send two commands (unless I'm missing something), 
do we want this? Do we want to recommend one of the two approaches? 
Should we add an example? Or am I completely off base?

Bye,
	Andrea

---

From: John Stracke <[email-masked]>
Date: Fri, 02 Aug 2002 17:30:16 -0400

Andrea Campi wrote:

> I'm not sure what's worse, really.

Well, but, if the server doesn't implement it, then the client's 
workaround isn't going to be atomic, either.  So a non-atomic 
implementation on the server is no worse than no implementation on the 
server, and is actually better because it preserves interop.

> I'd really like to be able to trust the server to not lose data. 

<shrug> Then don't use servers that aren't built on transactional 
databases.  Without that, it gets much harder to trust them.

-- 
/===============================================================\
|John Stracke      [email-masked]                      |
|Principal Engineer|http://www.centivinc.com                    |
|Centiv            |My opinions are my own.                     |
|===============================================================|
|"I use emacs, which might be thought of as a thermonuclear word|
|processor." -- Neal Stephenson                                 |
\===============================================================/

---

From: Andrea Campi <[email-masked]>
Date: Sat, 3 Aug 2002 00:46:03 +0200

> server, and is actually better because it preserves interop.

It was a rethorical question...

> databases.  Without that, it gets much harder to trust them.

Ok let's put it this way, then: if I were to write a client which needed 
to work with different servers, I'd like to be able to tell the user: 
this server doesn't support transactions, so you might risk some data. 
Or even refuse to talk to such a server! In fact, IMHO such a server 
would be really less useful than using iTIP over a  protocol such as 
email, and keeping a reliable data store on the client.

But to conclude, since we are really going off on a tangent here: I'm 
not saying that a server MUST do it atomically, only that it SHOULD. 
Personally I'd never write nor use a server which doesn't, nor can I 
imagine why somebody would want, but I guess someone will come up with a 
valid reason I haven't thought about...

Bye,
	andrea

---

From: [email-masked]
Date: Mon, 5 Aug 2002 13:27:22 -0400

> there's an UNPROCESSED entry with the same UID.

This smacks big time of feature creep that will drag out the process of 
creating CAP. 

If not careful we will wind up with just 1 command like 
"DOITALLTHEWAYIIMAGINEITSHOULDBE" and thats it.  Cool for CUA coders maybe 
but not for CS coders...

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: John Stracke <[email-masked]>
Date: Thu, 08 Aug 2002 13:32:25 -0400

[email-masked] wrote:

> This smacks big time of feature creep that will drag out the process 
> of creating CAP.    

I'm not so sure, actually; either we have feature creep or we have side 
effect creep.  Both take the same amount of effort to agree on; side 
effect creep probably adds more effort to implement (since it's harder 
to QA).

(Sorry about the delay in responding; I've been offline the past few days.)

-- 
/===========================================\
|John Stracke      [email-masked]  |
|Principal Engineer|http://www.centivinc.com|
|Centiv            |My opinions are my own. |
|===========================================|
|Newt Nuggets!                              |
\===========================================/