Re: Review of Reliable Messaging Spec v0-074

[Gordon van Huizen <gvanhuiz@progress.com>]

Jim,

> >2) Whether the reliability requirement is truly for AtMostOnce
> >semantics or for something more. An amount of the reliable messaging
> >spec goes well above the strict interpretation of AtMostOnce, with no
> >way to specify through the message header whether this is desired or
> >not. I have a longer diatribe about this in my Messaging Service spec
> >comments.
> 
> Fujitsu wrote a definition of 'RM' in the latest draft: AtMostOnce with
> timeout. Again, requesting other semantics (which are, of course, defined)
> is useful (and maybe mandatory) in the real world, but we should allow for
> a simple solution that will meet minimum needs.

I'm not requesting other semantics, but it seems that there are some
implied within the RM spec. Persistence of complete messages is not
necessary for AtMostOnce with time-out, and it seems to me that it
nudges into OnceAndOnlyOnce functionality. In any event, it is resource
intensive and has performance impact, and should therefore be
deselectable for messages that really only require AtMostOnce with
time-out.

-gvh-
begin:vcard 
n:Van Huizen;Gordon
tel;work:510-848-1988
x-mozilla-html:TRUE
url:http://www.sonicmq.com
org:Progress Software;XML and Internet Technology
adr:;;14 Oak Park;Bedford;MA;01730;
version:2.1
email;internet:gvh@progress.com
title:Director, Product Management
fn:Gordon Van Huizen
end:vcard