Hi Mike,
The 'last-document' flag in PSI is a legacy of IPP. It's
a kludge. A much cleaner solution is a distinct operation
"CloseJob" that is sent AFTER the last document is added
by Post (by value) or by Reference.
I'd much prefer that we corrected this mistake in IPP and
(therefore) the PWG Semantic Model.
Forcing mandatory support for AddDocumentByPost (and thus
an HTTP transport) is a bad mistake.
PSI should define clean WSDL/SOAP operations that can use
any transport binding of SOAP - SOAP over SMTP, or SOAP
over Blocks (RFC 3288), or whatever.
Cheers,
- Ira McDonald
High North Inc
PS - When we originally developed IPP/1.0, Microsoft only
wanted Print-Job (sends print data by value). Later,
Microsoft and many others realized that we SHOULD have
made support for Print-URI (sends print data by reference)
Mandatory and made Print-Job Optional.
-----Original Message-----
From: Mike Haller [mailto:mhaller@us.ibm.com]
Sent: Friday, February 28, 2003 2:53 PM
To: ps@pwg.org
Subject: RE: PS> Difficulty with AddDocumentByPost
Dave,
Thanks for the speedy reply. Response below.
> <dave>
> Hey Mike...
>
> Thanks for the input! See my comments inline...
>
> Would you be interested in attending some of our public
> interop events with your implementation? We plann on having
> some teleconference interops before a Face 2 Face event as well.
> </dave>
Harry has been talking to us about this, and we are definitely
interested. It will mostly be a question of whether we can catch up by
then.
> First, making the option mandatory will make it unnecessarily
> difficult to support an SMTP-bound SOAP implementation, since
> it forces an HTTP server implementation.
>
> <dave>
> Which option in particular are you refering to?
> </dave>
Well, I guess it's not really an option if it's mandatory :) I was
referring to the call AddDocumentByPost, which is listed as mandatory
for both a print service and a target device. Since it is required and
there is no fault for "operation not supported", then even a non-HTTP
SOAP implementation is forced to coordinate with an HTTP server. I
understand that the focus was on HTTP implementations, but this seems to
effectively preclude anything else.
>
> Second, allowing the lastDocument on this call means that
> heavy-duty coupling must be done between the JCI
> implementation and whatever implementation receives the SOAP
> calls, since the lastDocument = true must effectively be
> deferred until after the post has successfully completed.
> This implies that whatever receives the post must communicate
> with the JCI implementation when it has been received
> successfully. And of course, the JCI implementation already
> has to know all about whatever receives the post so that it
> can know how to create a new sink URL and go collect the data
> when it is done.
>
> <dave>
> Yep, this is very true, and I can't think of an easy way to
> decouple the JCI implementation from whatever receives the
> post. I think inherently that whatever receives the post
> needs to then add the data to the document that was created
> in the original AddDocumentByPost SOAP call. - I've managed
> this my placing a query parameter on the URL that is returned
> to the client as
> follows:
>
> We have a servlet that is listening on a particular path.
> The AddDocumentByPost returns the following:
> http://mypsiserver/axis/servlet/PSIPostServlet/urn:uuid:143832
> 734-2340342-34
> 34-3
>
> Basically, we encode the DocumentURI on the return path.
> This allows the servlet that receives the post to make the
> association with the appropriate internal JCI document as follows:
>
> protected void doPost(HttpServletRequest req,
> HttpServletResponse resp) throws ServletException, IOException {
> try
> {
> String documentURI = req.getPathInfo().substring(1);
> // Find the appropriate document from our
> PSIDocument hash
> PSIDocument doc =
> PSIDocument.getDocumentByURI(documentURI);
> InputStream requestInputStream = req.getInputStream();
>
> //Let the document object know about the input
> stream... doc.post(requestInputStream);
>
> // what do we return?
> resp.setContentLength(0);
> resp.getWriter().close();
> }
> catch (Exception e)
> {
> e.printStackTrace();
> throw new ServletException(e); // ???
> }
> }
> </dave>
>
> It is also unclear what the implementation should do if the
> post fails for some reason, or in what order the
> implementation can expect to receive the posts. For example,
> it now seems the client could:
>
> 1. CreateJob
> 2. AddDocumentByPost last = false
> 3. AddDocumentByPost last = true
> 4. Post document 2
> 5. Post document 1
>
> This makes the implementation difficult, without really
> seeming to buy anything useful for the client.
>
> <dave>
> This is also true. Right now I have solved this by deferring
> processing of the job untill all of the document data has
> been received. There are some gating factors as to what
> allows a job to be processed: lastDocument == true
> AllDocumentDataReceived == true </dave>
Technically this problem has a solution, even in the out-of-order case.
I think the real question is whether all the service implementors should
be burdened with this additional coupling when it can be fairly easily
be avoided without unduly limiting the client implementation (I think).
> If the lastDocument flag were removed from the
> AddDocumentByPost call, and if the additional requirement
> were made that the client could not perform any additional
> AddDocumentByReference or AddDocumentByPost calls until
> either the post was complete, or a CancelDocument call were
> made for the pending document, then the implementation would
> be much simpler. Then the example above would be:
>
> 1. CreateJob
> 2. AddDocumentByPost
> 3. Post document 1
> 4. AddDocumentByPost
> 5. Post document 2
> 6. AddDocumentByReference last = true reference = null
>
> <dave>
> I like the idea of adding the requirement that the data MUST
> be posted directly after the AddDocumentByPost, and before
> any other AddDocumentBy* methods are called. I'll add it to
> the latest rev of the spec, and see if the working group approves.
>
> I don't like overloading the AddDocumentByReference to
> indicate the "I'm Done". Hopefully adding the interleaving
> requirement is sufficient for you needs. </dave>
Then such an overloading does not already exist? That would seem to be
a problem, since you may not know at the time the last document is
started if it is the last document. I had assumed that PSI was similar
to IPP in that one of the AddDocumentByPost and AddDocumentByReference
was overloaded and could be used to end the job, but I did not find a
reference to this. Is there any way to do this, or is it always
necessary to know that a job will be complete at the commencement of the
last document?
Regards,
Mike
> Though I can't seem to find where AddDocumentByReference with
> a null reference and attributes is actually allowed (it is,
> isn't it?) Maybe it's not to late for a completeJob( jobURI ) call?
>
> Mike Haller
>
This archive was generated by hypermail 2b29 : Fri Feb 28 2003 - 17:57:24 EST