I forgot to include Ira as an attendee.
Alan
----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 : Fri Sep 13 2002 - 16:17:11 EDT