Hello Ira,
I just can't help but agree with all of your points.
Regards,
Mike
> -----Original Message-----
> From: owner-ps at pwg.org [mailto:owner-ps at pwg.org] On Behalf Of
> McDonald, Ira
> Sent: Friday, February 28, 2003 3:45 PM
> To: 'Mike Haller'; ps at 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 at us.ibm.com]
> Sent: Friday, February 28, 2003 2:53 PM
> To: ps at 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
> >
>-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2342 bytes
Desc: not available
Url : http://www.pwg.org/archives/ps/attachments/20030301/c9af197b/smime-0001.bin