Re: Message Pushing and TCP Transport

[Patrick <patrick@gandi.net>]

On Wed, Aug 29, 2001 at 08:29:04PM -0400, Eric Brunner took time to write:
> 
> >  ... the msqQ element of the <result> item of *any* command
> > tells him how many messages are waiting.
> > (see 2.5 of the EPP draft)
> 
> >From Sec. 4 Formal Syntax, Sub 1. Base Schema
> (Note: <qDate> added in the -03 to -04 delta)
> 
>     <complexType name="msgQType">
>       <sequence>
>         <element name="qDate" type="dateTime"
>          minOccurs="0" />
>       </sequence>
>       <attribute name="count" type="unsignedLong"
>        use="optional" default="0"/>
>     </complexType>
> 
> An unsigned long type holds the type-bounded number of enqueued messages.
> A dateTime type holds the temporal identifiers of message enquements. 
> 
> There is no guarantee that the value in the long and the ordinality
> of the dateTime sequences are equal.
> 
> Restated, there are N enqueued messages, and M temporal identifiers,
> in a msgQ element. M may be equal to, or less than, or more than, N,
> and the M temporal identifiers need not be unique, or ordered.
> 
> Finally, the msgQ element's value is associated with a command, having a
> fixed momentary value.
> 
> The atomicity of EPP operations does not necessarily extend the semantics
> of the msgQ values to the acutal enquements between commands, that is, it
> is not a sychronization primitive between queue reader and writer threads.
> 
> I'm sorry to be so long winded, I agree with your observation _most_ of
> the time. I wish I could agree with it _all_ of the time.

Except that in the setup I explained to you (that is viewing the
results of NON poll queries) the problem you outline is not there,
since the drafts says :
The <qDate>
element MUST be present when returning a message in a <poll>
response, and it MUST be absent otherwise.

When the client does it businnes, in any reply he may get a count
(but no qDate). If the count exist, it means message are waiting,
then it can do a poll to grab them.

Patrick.