Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "COSMOSDataCollectionMeeting20070821"

(New page: == Agenda == * Status updates and agenda changes * Review action items * Discuss moving to an earlier time slot * (Time permitting) Jimmy Mohsin's comments at the bottom of the Talk pa...)
 
(Discussion)
Line 24: Line 24:
 
== Discussion ==
 
== Discussion ==
  
* We discussed the "client API" in relation to bug 197870 and came to the conclusion that our contract with adopters is actually the WSDM web services APIs.  Programmatic APIs that isolate the adopter from the web services layer may be required in a variety of language bindings over time, but for now we believe that a one-to-one correspondence of Java convenience APIs with web services is adequate.
+
* We discussed the "client API" in relation to bug 197870 and came to the conclusion that our primary contract with adopters is actually the WSDM web services APIs.  Programmatic APIs that isolate the adopter from the web services layer may be required in a variety of language bindings over time, but for now we believe that a one-to-one correspondence of Java convenience APIs with web services is adequate.
  
 
* We discussed the design page for the broker at length.  We decided that recovery and restart is outside our scope for the near term.  We also decided that workflow is an application consideration as opposed to part of the client API.  We discussed the broker lookup API and agreed that a simple mechanism will be sufficient for some use cases in the near term and that we need to reserve the flexibility to integrate the broker with CMDBf in the future.
 
* We discussed the design page for the broker at length.  We decided that recovery and restart is outside our scope for the near term.  We also decided that workflow is an application consideration as opposed to part of the client API.  We discussed the broker lookup API and agreed that a simple mechanism will be sufficient for some use cases in the near term and that we need to reserve the flexibility to integrate the broker with CMDBf in the future.
  
* The group agreed to complete the design document prior to tomorrow's architeture call.
+
* The group agreed to complete the design document prior to tomorrow's architecture call.
  
 
== Action Items ==
 
== Action Items ==
  
 
* Martin agreed to complete the broker design page prior to the 8/22 architecture call.
 
* Martin agreed to complete the broker design page prior to the 8/22 architecture call.

Revision as of 16:21, 21 August 2007

Agenda


Attendees

  • Don Ebright
  • Joel Hawkins
  • Jimmy Mohsin
  • Martin Simmonds
  • Hubert Leung
  • Mao Sheng
  • Bill Muldoon
  • Jack Devine
  • Paul Stratton

Discussion

  • We discussed the "client API" in relation to bug 197870 and came to the conclusion that our primary contract with adopters is actually the WSDM web services APIs. Programmatic APIs that isolate the adopter from the web services layer may be required in a variety of language bindings over time, but for now we believe that a one-to-one correspondence of Java convenience APIs with web services is adequate.
  • We discussed the design page for the broker at length. We decided that recovery and restart is outside our scope for the near term. We also decided that workflow is an application consideration as opposed to part of the client API. We discussed the broker lookup API and agreed that a simple mechanism will be sufficient for some use cases in the near term and that we need to reserve the flexibility to integrate the broker with CMDBf in the future.
  • The group agreed to complete the design document prior to tomorrow's architecture call.

Action Items

  • Martin agreed to complete the broker design page prior to the 8/22 architecture call.

Back to the top