OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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]