RE: RM Group Definitions

[mwsachs@us.ibm.com]

In my opinion, there are many pitfalls in the grouping which we haven't yet
identified.  I suggest starting with a group size of 1 and after the first
specification is approved, we can start working on enhancements such as
grouping.

...and please, let's remember that the efficiency of the reduced number of
ACKs is paid for by increased message latency waiting for each group to
complete and be acknowledged.  In my comments to the draft specification, I
pointed out at least one reason why the group has to be completed before
the messages can be passed to the application - preventing retried messages
from being out of order.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Jim Hughes <jfh@fs.fujitsu.com> on 08/29/2000 04:40:57 AM

To:   ebxml-transport@lists.ebxml.org
cc:
Subject:  RE: RM Group Definitions



Then we need to come to a quick resolution on this point in the group. If
message grouping (by this I mean sending only one MSH-level ACK for a group
of reliable messages) is not allowed, then it greatly simplifies the RM
spec... I suggest we carefully consider this before taking the decision for
this level of simplicity may yield an unacceptable solution.

Jim

At 03:47 PM 8/28/2000 -0500, richard drummond wrote:
>i don't think grouping is appropriate at this time. we need to keep it
>simple for the first round of ebxml... that is that though the end of may
>next year..... rik