Won't work, unfortunately. There are a couple problems:
1. HTTP/1.1 connections only persist for a little while, and that ill-=
defined
while is likely to be short relative to, say, the time required to proc=
ess a
print job. See "HTTP Connection Management" at
ftp://ietf.org/internet-drafts/draft-ietf-http-connection-00.txt
2. The client has to be expecting new data to arrive after the initial=
response. If the response has Content-Length, a normal HTTP client wil=
l only
read that much content from the connection before the next request is i=
ssued.
You might be able to fake around these obstacles by using chunked trans=
fer
encoding in the response. However, I think this would be considered ab=
use of
the protocol, and is likely to fail if there are any proxies in the
communication path.
> the server can wait until the same client
> opens another session, provided that the server can
> uniquely identify the client. For completeness, a
> time-to-live for the message may need to be defined.
This could work. Something like this is allowed by the current IPP mod=
el and
protocol. The client polls with Get-Job-Attributes looking at job-stat=
e,
job-state-reasons, and/or job-state-message. After processing is compl=
ete, the
server could wait for a poll for a particular job-id or job-uri before
forgetting the job, with some time-out. However, nothing in IPP says t=
he
server shall remember the job once it's complete; that's implementation=
dependent.
-Carl Kugler
ipp-owner@pwg.org on 02/03/98 12:21:17 PM
Please respond to ipp-owner@pwg.org @ internet
To: ipp@pwg.org @ internet
cc:
Subject: Re: IPP> Notifications
I don't see there is any need for the client to open
another socket waiting for the server notification.
Since an IPP connection is persistent, the server can
notify the client over the same socket any time. If
a notification needs to be sent after the session is
closed, the server can wait until the same client
opens another session, provided that the server can
uniquely identify the client. For completeness, a
time-to-live for the message may need to be defined.
What this means is that if the client is ever interested
in any notification from the server, it should remain
online or check back with the server later.
=