sendid

Considering our previous discussions on that matter, I have a proposal for a revised sendid behavior:

Each <send> is given a static (and unique) sendid, either by the author or automatically by the platform.

Then, each time the <send> is executed, a platform-generated instanceid is associated to that particular instance of the <send>. The instanceid must not contain the "." character and be unique for that particular <send> element.

The string "$sendid.$instanceid" can be retrieved by using the idlocation attribute, which is therefore no longer mutually exclusive with the id attribute (which should be renamed sendid just like the id attribute of <data> elements should have another name, BTW).
The generated sendid can be easily extracted by removing the last segment beginning with "." from the value assigned to the idlocation.

Executing <cancel> with the sendid alone will cancel all instances of the <send>, while passing it the full sendid.instanceid will cancel only that instance.

Alternatively, <cancel> could get a new boolean attribute "all" that would make the interpreter automatically strip the instanceid if present. Just in case some datamodels are not so good at manipulating strings but want to spam <send>s anyway.

This proposal allows authors to choose their <cancel> granularity if and when they actually use <cancel>, rather than having to think ahead and choose to name their <send> or not.

As to the "sendid" property in _event, I maintain that it is inadequate to provide it with a successfully sent event.

			David

Received on Tuesday, 16 April 2013 09:30:25 UTC