Re: Message Pushing and TCP Transport

[Patrick <patrick@gandi.net>]

On Sat, Sep 01, 2001 at 12:29:55PM -0400, Eric Brunner took time to write:
> >> How many messages are waiting?
> >
> > The value of the count attribute.
> > Reading the draft :
> >   - An OPTIONAL <msgQ> element containing a "count" attribute that
> >     identifies the number of service messages queued for client
> >     retrieval.
> 
> So no messages are deleted from or added to the queue subsequent to the
> (atomic) set of events in which a value is written to msgQ->cnt, and the
> (atomic) set of events when, to use your original, the registrar "gets
> them[.] (immediately or later at its convenience)"?

Imagine the client receive the information : 1 message waiting... but
another one came at the same time (since this is what you imagine, if
I understood you correctly).
The client *think* there is only one *new* message.
So it does a poll to take it.
With the result it sees that is another one he was not aware of
previously. Thus he can do the poll again.

Even if the second message came later, the client will again later
obtain the information it is waiting.

Where is the big deal ?

BTW also if we take a *real* case (not some sort of pure
conjectures...) like using those messages for transfers notification,
they do not came 10000/hour or day either...

> Just to be sure, and I'll make this my last question to you, how many
> messages are waiting?

Trying to make me look stupid has no real value I think.
I do not think that the provreg protocol want to define precisely how
to count how many messages are waiting. I think that no real
implementation will care about that.  What is important is *if*
messages are waiting or not.

Let me try to again phrase my position (after that I think this
thread should be closed), because either I am not clear enough, or
you do not seem (to want) to see my point :

People are objecting to the poll because it creates overhead (mainly
because it needs that clients periodically connect to know if
messages are waiting, they say).

I say it is false since there is no need to do specific polls to know
if messages are waiting, since the draft is good enough to provide
this information in *normal* results, ie usual business.
Using poll, client has nothing to do. It does its usual business.
Some times he will be warned that they are new messages. After that
it is up to it to handle this correctly. This *only* was my point.
About semantics you will need to see with the author of the draft, it
is not my concern here.

For the record, I agree to have the PUSH as a MAY, however I totally
disagree to say that the POLL is bad and should be replaced by the
PUSH. The POLL should be a MUST and the PUSH a MAY.

Regards,
Patrick.