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

From: "Yang, Lily L" <[email-masked]>
Date: Fri, 15 Oct 2004 15:51:42 -0700

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: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 15 Oct 2004 17:19:09 -0700

It makes sense to combine ADD, DEL, UPDATE, etc...we already have this
in our Config msg.
The question is whether you would need a GET operation as part of this
message as well, or it would work better as a separate message...for
e.g., Query msg as we have in the protocol.

Jamal provided a good clarification on this.

Thanks
Hormuzd

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

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

At 03:55 PM 10/15/2004 -0700, Khosravi, Hormuzd M wrote:
>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
>
>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 ?
>

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sat, 16 Oct 2004 00:33:46 -0700

Sure Ellen, i agree with that general notion as well...my question was
more specific...to find out if there is a good rationale or example to
combine SET like operations (SET, DEL, etc) with GET operation.

I have implemented this both ways only to find that even when I could
combine Set/Get in a single message, we always used them in separate
msgs. So having them as separate msgs just seems more practical and a
side benefit of that is it makes the parsing a little bit faster...not a
whole lot I admit.

My 2 cents,
Hormuzd  

-----Original Message-----
From: Deleganes, Ellen M 

The thing that is appealing about the proposal is not so much being able
to combine operations as the notion of being able to define new ones
without having to define new messages.