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: time management: the options

Title: time management: the options

Here is a summary of the two major options I believe we face about dealing with timing, as outlined in previous mails,
and my analysis of their advantages / disadvantages.
After consideration, I personally favor Proposal #1 (the one we started on at f-2-f).

Tomorrow I will map this time management proposal to our list of current issues,
and propose corresponding resolution/impact to several of them.
The schema so far is same as last proposed in f-2-f.


Proposal #1: (use time parameters)
Uses ExpiryTime, GroupExpiryTime, MaxGroupIdleTime, here carried in the protocol
(messages), as discussed last f-2-f.
The group termination follows rules based on these values, as we outlined them
in f-2-f, and of which I propose/summarize a complete version in draft sent out Nov 2.

- group duration, scope of duplicate check, is clearly controlled
by these parameters. Semantics is clear to users.
- control of storage space is better (much less chance to overflow available space)
- synchronization between sender and receiver via protocol (same understanding
on both sides, of persistence conditions).

- possible abuse by users (the RMP may have to "cap" these values, based
on some configuration).
- implementors must implement these rules in order to conform to spec (more complex).

Proposal #2: (timeless)
Does NOT specify ExpiryTime, GroupExpiryTime, MaxGroupIdleTime.
Instead, groups and message IDs are kept open and persisting until some garbage
collection takes place, controlled by config for each implementation.

- no "termination" management is required to conform to specification. Simpler spec,
Easier to implement.

- the contract about the scope of dup elimination, of group duration, is unclear
as controlled by storage availability, possibly differently by each impleemntation.
- synchronization of termination and removal of states between Sender and Receiver unclear.
- more chance to overflow available storage, watermark parameters for space limits
will be reached more often, making terminations of persisted groups and message IDs

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]