RE: Poll response data

[Sheer El-Showk <sheer@saraf.com>]

My apologies for the continued confusion, let me try to make my suggestion
clearly and give a brief justification and then let everyone descide
whether its useful or not.

The idea is to include a timestamp in each poll response that would
indicate the time the queue update process was mostly recently run.  This
is NOT the time that the queue was last polled by a registrar (which would
be superflous as Scott and Chris have pointed out).  Nor is it
necassarily the time the most recent (as opposed to last, since as
Chris mentioned the most recent message could have been dequeued and an
earlier message would now be the last message on the queue) message was
placed on the queue, but rather the last time that the process that places
messages on the queue was actually run.

To give a concrete example, I might use a cron job running every two hours
to scan my registry database for queable records and then make entries in
another database used by the queue server.  Even if my process finds no
records in the registry database that need to be queued, it will still
mark my queue database (in a header or special purpose record) every two
hours to indicate that the queue represents the state of the registry up
until this point in time (the time the last cron job was run).  Since this
timestamp is then passed on to registrars with each poll request they
know how recently the queue was synchronized with the canonical data
source (the registry database) -- a useful piece of information in my
opinion.  This presumes queue updates will be a batched process rather
then some event-driven (pushed) system such as refreshing the queue in
real-time as events occur at the registry.   Even in the later case
however, it will be useful to know that the queue represents the state
of the registry in real time.


I hope that I've managed to convey this clearly this time.  I would like
to see what people think about this once its been conveyed properly.

Regards,
Sheer

On Wed, 27 Jun 2001, Hollenbeck, Scott wrote:

> Sheer,
>
> Now I'm getting confused.  If your suggestion is to note when the queue is
> updated, that happens every time is message is either enqueued or dequeued.
> So, pulling off a message would result in an update, and I'm not sure that
> the date and time of that event is of any value at all because the client
> already knows exactly when it happened because they caused the update.
>
> When you wrote "updated", did you mean "had a message added to the end of
> the queue"?  After thinking about that a bit, I'm not sure that this
> provides any really useful information, either.  The protocol currently
> provides a queue counter that tells the client how many message are queued
> for delivery.  If a client gets an indication in a response that there are
> "n" queued messages, I've thought (and I may be wrong) that clients will
> typically want to retrieve all of the queued messages at once through a
> series of "n" <poll> requests and acks without really worrying about when
> the last message was added.
>
> Could someone else with a client perspective provide any insights into ways
> that a "last updated" or "last queued" time would be valuable or not?  I'm
> OK with noting a date-time on each queued message, but I'm not so sure about
> the utility of this second date-time.
>
> <Scott/>
>
> >-----Original Message-----
> >From: Sheer El-Showk [mailto:sheer@saraf.com]
> >Sent: Tuesday, June 26, 2001 2:05 PM
> >To: Bason, Chris
> >Cc: 'ietf-provreg@cafax.se'
> >Subject: RE: Poll response data
> >
> >
> >Hi Chris,
> >
> >I think this concept makes a lot more sent if you think of it as a "queue
> >last updated" timestamp rather than a "last message queue time" (my
> >careless wording initiall, I apologize).  The idea is that the queue
> >structure (in memory or in a database or whatever) would maintain a
> >timestamp indicating the last time it was updated.  It would then
> >prepend/append this to any response to a <poll> request.  This wouldn't
> >be part of the actually queue message, but status information about the
> >overall queue.  In fact, if the queue is updated (by whatever batch or
> >synchronus process updates it) without any messages being added then this
> >time will be very different from a "last message queued" timestamp.
> >
> >The idea behind this is to give the polling registrar an idea of the
> >freshness of the queue overall.  If I'm polling for the state of a
> >transfer request and see only an "awaiting acknowledgement" message queued
> >two days ago it makes a big difference to me whether the queue was last
> >updated a few minutes ago or two days ago.  The idea is to allow automated
> >registrar systems to determine if they need to actively query for more
> >detailed information.  Of course, I think, if all these systems are kept
> >near real time then a lot of this will be redundant, but that expectation
> >can't be built into the protocol.
>