PSI Working Group:
*Alan Berkema Gail Songer *Dave Hall
Jerry Thasher Harry Lewis *Ted Tronson
Peter Mierau *Peter Zehler Paul Tykodi
Bob Taylor Don Levinstone Lee Farrell
Don Wright Kirk Ocke Ira Mcdonald
Amir Shahindoust
* = attendance
09/10/02 Agenda
1) Review the PSI schedule
2) Review the targetDeviceSupport interface
Minutes:
Thinly attended, however it was still a very productive meeting.
1) Review the PSI schedule
See schedule attached.
By the end of September we will attempt to get the spec to
rev 0.9. This will include the spec. and the logical view in a
single document. We need to resolve all the outsatnding issues
or jetison the feature to Post 1.0. It will also add the WSDL/SOAP
for the methods. I realize this is aggresive, however, we definately
won't make it if don't try for it. When we post .9 we have a few
phone conferences to continue to work on it. On October 22 we will
post the revisions as a .93 spec, two week before the Novemebr F2F.
.93 is the candidate .95 spec. We will review this and changes will
become the .94 spec. Apx. two weeks after this I will call for a vote
to promote this to 0.95. The philosophy behind setting an aggressive
schedule in the charter was to enable a base level of PSI functionality
to test it and attempt to foster early market adoption, rather than work
on a spec for multiple years that covers everything.
2) Review the targetDeviceSupport interface
associateTargetDevice(), does this belong in 1.0? Ira commented
that this isn't specified well enough and "a mircle needs to happen"
for this to work. Take a look and we will revisit at the next call.
The postStatus methods were changed to
sendServiceNotifications
sendJobNotifications
sendDocumentNotifications
sendServiceNotifications includes
jobState, jobStateReasons and an eventID.
These are all simple noticiations that do not involve subscriptions.
The above conclusion was reached via an involved discussion about
notifications in general, subscriptions, and why are we doing notifications
at all and why are we doing them in the targetDeviceSupport interface?
Conclusion is that the targetDeviceSupport interface is primarlly used
when the targetDevice is behind a firewall and the PS cannot do a
getJobAttributes. We need a boolean that tells the targetDevice if the PS
wants notifications or not. We previously thought that this would go in the
createJob, however since the notifications are only used with the
tagetDeviceSupport interface we deiced to put the boolean in the getNextJob.
Is it also in getNextDcoument? forgot where we landed.
Discussion about getKnowTargetDevices, does this belong in the
targetDeviceSupport? I think we decided to move this to jobControl?
that is all,
Alan
This archive was generated by hypermail 2b29 : Thu Sep 12 2002 - 17:25:12 EDT