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.

Jacques

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.

Advantage:

- 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).

Drawbacks:

- 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.

Advantage:

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

Easier to implement.

Drawbacks:

- 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 

unpredictable.