[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Preliminary minutes of WSRM TC Conf call -050603
<iwasa> > > Making GroupID mandatory for all messages, > SequenceNumber mandatory only for ordering, > and MessageId optional or remove it completely. > The GroupID must be globally unique. > > With this resolution, GroupId is equivalent with > Globally unique message ID, if you do not do > ordering. And ordering can be done within a group > with SequenceNumber. > > We can change the element name also if we want. > Eg. GroupID to MessageGroupID > </iwasa> +1. More crispy that what I mentioned before. A more concrete refinement would be: - Remove the <rm:GroupId> element from <rm:MessageOrder> - Add 'status' attribute to <rm:SequenceNumber> - Use of <rm:MessageOrder> Header differentiates ordered to non -ordered - MessageId is GUID for non-ordered. - Sequence no. is unique within a group (for the same MessageId) Thanks, -Sunil > > I believe this resolution solves all issues we have. > > Thanks, > > Iwasa > > > > > >4.4 REL-11 MESSAGE ID AND GROUPID/SEQUENCENO > > ... > > >Paulo stated that having two identifiers (such as groupID, sequenceNO) is > > >needed for several groups of messages with dependencies. Messages ordered > > >by groups is a use case we have often. He also would prefer one id > > >mechanism, but it could be a struct with groupID > > > > I guess I must have missed a "not" in the yesterday phone call... > > Actually, I can't imagine many common use cases where between two end > > points it is necessary to have simoultaneously multiple groups of messages > > which have to be ordered independently. This is why I consider redundant > > having two different identifiers (Group_id + Sequence_id), and I would > > prefer to use only one identifier for both duplicate elimination and > > sequence ordering. The advantages of such an approach would be: > > implementation simplification and reduced "verbosity" => overhead. > > > > May be somebody can show us some use cases where the feature of having > > multiple groups of messages ordered is worthy the cost of using distinct > > identifiers for ordering and filtering out duplicates. > > > > Paolo
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]