Printer Services Mail Archive: RE: PS> Difficulty with AddDo

RE: PS> Difficulty with AddDocumentByPost

From: Mike Haller (mhaller@us.ibm.com)
Date: Sat Mar 01 2003 - 12:48:18 EST

  • Next message: Wagner,William: "PS> RE: PSI and Port 80, and printers traversing the firewall"

    Hello Ira,

    I just can't help but agree with all of your points.

    Regards,
    Mike

    > -----Original Message-----
    > From: owner-ps@pwg.org [mailto:owner-ps@pwg.org] On Behalf Of
    > McDonald, Ira
    > Sent: Friday, February 28, 2003 3:45 PM
    > To: 'Mike Haller'; ps@pwg.org
    > Subject: RE: PS> Difficulty with AddDocumentByPost
    >
    >
    > 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
    > >
    >



    • application/x-pkcs7-signature attachment: smime.p7s



    This archive was generated by hypermail 2b29 : Sat Mar 01 2003 - 12:49:03 EST