Peoples, THe agreement out of our last meeting was to introduce the querySynch() command to support a synchronous (blocking) summary query command. This operation would not support the detailed query behaviours. To maintain consistency in operation naming, I would like to break the current asynchronous query operation into two separate commands: query() that would provide the asynchronous summary query for the schedule, and queryDetails() that would provide the recursive tree view of the schedule. query() would have the same parameters and confirmation result type as querySynch(). If people support this change, then I will go ahead and make it at the same time I add the querySynch() operation. I am open for naming changes as well. If someone thinks querySummary() and querySummarySynch() are better operation names. Thank you, John
John, Splitting the Query into two parts makes reasonable sense to me since we already half-way there as we have two response types: QuerySummaryResult and QueryDetailedResult. Guy -----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of John MacAuley Sent: 28 January 2013 13:56 To: nsi-wg@ogf.org Group Subject: [Nsi-wg] Query renaming Peoples, THe agreement out of our last meeting was to introduce the querySynch() command to support a synchronous (blocking) summary query command. This operation would not support the detailed query behaviours. To maintain consistency in operation naming, I would like to break the current asynchronous query operation into two separate commands: query() that would provide the asynchronous summary query for the schedule, and queryDetails() that would provide the recursive tree view of the schedule. query() would have the same parameters and confirmation result type as querySynch(). If people support this change, then I will go ahead and make it at the same time I add the querySynch() operation. I am open for naming changes as well. If someone thinks querySummary() and querySummarySynch() are better operation names. Thank you, John _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Mon, 28 Jan 2013, John MacAuley wrote:
THe agreement out of our last meeting was to introduce the querySynch() command to support a synchronous (blocking) summary query command. This operation would not support the detailed query behaviours.
To maintain consistency in operation naming, I would like to break the current asynchronous query operation into two separate commands: query() that would provide the asynchronous summary query for the schedule, and queryDetails() that would provide the recursive tree view of the schedule.
Sounds good. The structure in the reply is a bit odd.
I am open for naming changes as well. If someone thinks querySummary() and querySummarySynch() are better operation names.
I'm okay with the Summary name. However I think that usually one abbreviates synchronous as "sync", without the h. I also find the queryDetails name a bit misleading, as it doesn't really reflect the nature of the request. Maybe queryTree/treeQuery or queryRecursive? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Okay "sync" it is. I went through this when naming the original query options. Tree is a bit specific to the deployment and reservation since it could be a chain :-) Recursive might be better, but let me thing about it. On 2013-01-28, at 9:42 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Mon, 28 Jan 2013, John MacAuley wrote:
THe agreement out of our last meeting was to introduce the querySynch() command to support a synchronous (blocking) summary query command. This operation would not support the detailed query behaviours.
To maintain consistency in operation naming, I would like to break the current asynchronous query operation into two separate commands: query() that would provide the asynchronous summary query for the schedule, and queryDetails() that would provide the recursive tree view of the schedule.
Sounds good. The structure in the reply is a bit odd.
I am open for naming changes as well. If someone thinks querySummary() and querySummarySynch() are better operation names.
I'm okay with the Summary name. However I think that usually one abbreviates synchronous as "sync", without the h. I also find the queryDetails name a bit misleading, as it doesn't really reflect the nature of the request. Maybe queryTree/treeQuery or queryRecursive?
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (3)
-
Guy Roberts -
Henrik Thostrup Jensen -
John MacAuley