Subject: [Forces-protocol] RE: GET/SET in one msg ?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 15 Oct 2004 15:55:41 -0700

No, I don't that's why I asked...since this was coming from Joel's
proposal.
I didn't get a good reason from his email either, but it seems like he
would like to have it supported by the protocol anyway.

Joel, do you have any examples for us ?

Thanks
Hormuzd 

-----Original Message-----
From: Yang, Lily L 
Sent: Friday, October 15, 2004 3:52 PM
To: Khosravi, Hormuzd M; 'Joel M. Halpern'; [email-masked]';
'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M; [email-masked]'
Cc: [email-masked]'
Subject: RE: GET/SET in one msg ?

I don't understand why you would want to do such a thing. Do you have
any example in mind? 

> -----Original Message-----
> From: Khosravi, Hormuzd M 
> Sent: Friday, October 15, 2004 2:04 PM
> To: Joel M. Halpern; [email-masked]; Steven Blake; 
> Yang, Lily L; Alan DeKok; Deleganes, Ellen M; [email-masked]
> Cc: [email-masked]
> Subject: GET/SET in one msg ?
> 
> Hi Folks,
> 
> We (protocol team) are finalizing some of the msgs and one of 
> the issues which is being discussed is whether GET/SET 
> operation need to be combined in a single msg...(currently we 
> have them as separate msgs). I have never seen this being 
> done in practice i.e. command bundling of GET/SET, but if you 
> guys have some experience/opinions on this, pls do let us know.
> 
> 
> Thanks a lot,
> Hormuzd
> 
> 

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: Jamal Hadi Salim <[email-masked]>
Date: 15 Oct 2004 20:09:12 -0400

The question is not well worded.

The real question should be whether the SET and or a GET should be
using the same construct.
As a reminder, we have the follwoing construct: 

Type{=config}->FE->LFBClass->LFBinstance->operation= {SET}-->data here

1) What we have in the currently discussed BNF is GET resides in the
spot where SET is.

2) What we had before is a special type called query just for getting
things.

** A side effect of batching multiple operations is ability to do a GET
and a SET (or an add and a delete etc).

The comparison is between #1 and #2 above.

Should we keep the GET as in #1 or keep the query type in #2?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Oct 2004 20:11:36 -0400

If we are sure that the only two operations we will ever need are GET and 
SET, then we could probably simply declare that a message was either a GET 
message or a SET message.
However, we have had suggestions of INSERT operations, and I would hate to 
design the protocol so that we could not add other operations later.  And 
some combinations of operations may make sense together (insert item 
A.  Add reference to A in item B.  Delete obsoleted item C.)
Thus, I tend to think that it makes sense to structure the protocol so that 
a single emssage can carry multiple operations.
At the same time, as I said earlier, I would either prohibit or warn 
against combining update and read operations in the same request.  Requests 
to read, for example to confirm the results of an update, ought to be sent 
separately so that the FE does not need to worry about the order of 
application.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Oct 2004 20:12:58 -0400

I personally prefer that the message type be independent of the operation 
type.  Thus if we create conditional gets, or test and set, or any other 
interesting operations we don't have to discuss whether ti goes in the GET 
message or the SET message.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: 15 Oct 2004 20:21:17 -0400

> message or the SET message.

Can you be more specific in the case of the config/set vs query
examples? Thats whats on our immediate plate

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 15 Oct 2004 20:40:52 -0400

Joel,
We are sort of in a rush here to beat a deadline ;-> Give it to us in
boolean logic please ;->

Did i read correctly that since we may have multiple operations (we have
been discussing event un/subscribe as something that would appear as an
operation for example) then the way to go forward is have GET as an
operation?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Oct 2004 21:20:07 -0400

That would be my suggestion.

To be specific, I would not have a Query and a Modify message, but rather 
would have an Operation message which can carry whatever operations we 
decide we need.  We may make specific rules that say "for sanity, never 
combine X and Y".

I believe this will keep the protocol simpler.

Yours,
Joel