On 07/09/2012 23:40, Chris Barrow wrote:
> Hi Nigel,
>
> In #1 I think you meant JMSDeliveryTime.
Yes, indeed I did. Here's the corrected text:
I propose to clarify the definition of the new JMSDeliveryTime message property to be "the difference, measured in
milliseconds, between the delivery time and midnight, January 1, 1970 UTC."
> I agree with your proposals, and clarity is good! Perhaps for #2 (JMSExpiration) the spec could use the word SHOULD
> rather than MUST if must would be too strict for certain existing behaviors.
That's a possibility (though I would prefer to use the words "is recommended to" when mentioning non-mandatory
behaviour). Any other views? Mandatory / recommended / no change?
This proposal is whether we can clarify the definition of the JMSExpiration message property to be "the difference,
measured in milliseconds, between the expiry time and midnight, January 1, 1970 UTC"
> However, on the other hand one could argue
> that since this is a major release of the JMS spec some backward incompatibility might be permissible. But it sounds as
> if you have a strictly forward compatible philosophy here.
If the existing spec had unambiguously defined JMSExpiration then we should definitely not change the definition to
something else. But since it is currently defined somewhat vaguely we have a certain amount of scope to replace it with
a less vague definition, if we think this is appropriate.
Nigel
> Chris
>
> On 9/7/2012 8:53 AM, Nigel Deakin wrote:
>> Whilst updating the API docs for delivery delay I had one small additional thought on delivery delay.
>>
>> Currently the JMSDeliveryTime message property is defined as "the sum of the message's delivery delay and the GMT it
>> is sent".
>>
>> I chose this wording to keep it consistent with the definition of the JMSExpiration message property, which is "the
>> sum of the time-to-live value specified by the client and the GMT at the time of the send"
>>
>> However since in both cases these property are long values (rather than Date values) and so this is rather ambiguous
>> as it does not specify how the actual delivery time is converted to a long.
>>
>> Since JMSDeliveryTime is a new property we are free to define it however we like. I would like to suggest that we
>> define it as being defined as "the difference, measured in milliseconds, between the delivery time and midnight,
>> January 1, 1970 UTC".
>>
>> This means a JMS provider could set the delivery time header at the time of the send by adding the delivery delay to
>> System.currentTimeMillis().
>>
>> It would be nice if we could clarify the definition of JMSExpiration in a similar manner, but since this is an old
>> property we may have to leave the definition vague in case a current JMS provider currently uses a different
>> implementation and applications rely on it.
>>
>> So:
>>
>> 1. I propose to clarify the definition of the new JMSExpiration message property to be "the difference, measured in
>> milliseconds, between the delivery time and midnight, January 1, 1970 UTC". Any comments?
>>
>> 2. I'd like to invite views on whether it is desirable to, and also safe to, change the definition of JMSExpiration in
>> a similar manner. If we're not sure I will leave this unchanged.
>>
>> Nigel
>