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

RE: PS> Difficulty with AddDocumentByPost

From: HALL,DAVID (HP-Vancouver,ex1) (dhall@hp.com)
Date: Fri Feb 28 2003 - 11:48:32 EST

  • Next message: BERKEMA,ALAN C (HP-Roseville,ex1): "PS> [PSI]: next call 03/04/03"

    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

    -----Original Message-----
    From: Mike Haller [mailto:mike.haller@attbi.com]
    Sent: Friday, February 28, 2003 7:08 AM
    To: ps@pwg.org
    Subject: PS> Difficulty with AddDocumentByPost

    I have an implementation of the job control interface circa last
    November, and am finally getting around to updating it to something
    more
    modern (20030221), but I am finding the new AddDocumentByPost
    difficult
    to implement.

    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>

    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:143832734-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>

    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>

    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 - 11:48:45 EST