Latest version with Steven's comments and spell-checked. Informational Section --------------------- Area: Applications [Standards] Name of group: Simple API for Grid Applications Core Working Group Acronym: SAGA-CORE-WG Type of group: Working Group (WG) Chairs: Tom Goodale, Andre Merzky Secretaries: TBD Email list: saga-core-wg@ggf.org Web page: http://forge.ggf.org/projects/saga-core-wg/ Charter: ------- Focus/Purpose: ------------- The SAGA-RG coordinates the development of simple, application oriented APIs for Grid Applications. This working group is the first working group spawned by the RG, and will concentrate on producing concrete API documents for the functional areas identified by the initial SAGA-RG design team. Specifically: - Files - Logical files - Job submission and management - Streaming communication between processes along with the core API areas which are independent of specific Grid operations: - Tasks - Sessions - Security Scope: ----- The initial SAGA-RG collected a number of application use cases which are published in the GGF Document number GFD-???. The work of this group will be based on this use cases, which will define the scope and target application areas for the API. Simplicity and conciseness will be the governing design principles. The specification of services and the protocols to interact with them is out of the scope of the WG. Rather, the API seeks to hide the detail of any service infrastructures that may or may not exist to implement the functionality that the application developer needs. The WG will, however, actively liaise with relevant grid-middleware groups within the GGF. The WG will continue to identify projects outside GGF with similar API-focus and goals, and will seek their input in the development of the API and its implementation. The WG will provide detailed non-normative examples and 'cook-books' showing how the specified APIs could be used. Exit Strategy: -------------- The group will finish its work after the publication of the API Specification as GGF standard recommendation, accompanied by documents for API language bindings. Goals: ------ The SAGA-CORE-WG is the first WG spawned by the SAGA-RG, which produced the informational document ("SAGA Use-Case Document, version 1"), and is producing a related requirements document. The main goal of the WG is the creation of an API specification for the functional areas defined in these documents and explored by the first SAGA-RG design team, as listed above. This API will be submitted to GGF as a standard recommendation. The WG will produce the following documents: * Informational Document: "Abstract SAGA-CORE-API Specification" The initial SAGA API specification in SIDL, which is language neutral. * Recommendation documents: Language bindings for the "Abstract SAGA-CORE-API" specification These will be for a number of languages, such as C, C++, Java and Fortran. Milestones: ----------- GGF16: - SAGA API Specification pre-v1.0 GGF17: - Submission of abstract SAGA API Specification v1.0 - Implementation details review. GGF19: - Present Draft Language Bindings (C/C++/Java/Fortran)
Hi Tom,
* Informational Document: "Abstract SAGA-CORE-API Specification" The initial SAGA API specification in SIDL, which is language neutral.
I think that should be recommendation document - that was the goal behind the whole exercise of bit flipping :-) Cheers, Andre. Quoting [Tom Goodale] (Feb 09 2006):
Date: Thu, 9 Feb 2006 07:00:15 -0600 (CST) From: Tom Goodale
To: saga-rg@ggf.org Subject: [saga-rg] SAGA-CORE-WG charter revision 2 Latest version with Steven's comments and spell-checked.
Informational Section ---------------------
Area: Applications [Standards]
Name of group: Simple API for Grid Applications Core Working Group
Acronym: SAGA-CORE-WG
Type of group: Working Group (WG)
Chairs: Tom Goodale, Andre Merzky
Secretaries: TBD
Email list: saga-core-wg@ggf.org
Web page: http://forge.ggf.org/projects/saga-core-wg/
Charter: -------
Focus/Purpose: -------------
The SAGA-RG coordinates the development of simple, application oriented APIs for Grid Applications. This working group is the first working group spawned by the RG, and will concentrate on producing concrete API documents for the functional areas identified by the initial SAGA-RG design team. Specifically:
- Files - Logical files - Job submission and management - Streaming communication between processes
along with the core API areas which are independent of specific Grid operations:
- Tasks - Sessions - Security
Scope: -----
The initial SAGA-RG collected a number of application use cases which are published in the GGF Document number GFD-???. The work of this group will be based on this use cases, which will define the scope and target application areas for the API. Simplicity and conciseness will be the governing design principles.
The specification of services and the protocols to interact with them is out of the scope of the WG. Rather, the API seeks to hide the detail of any service infrastructures that may or may not exist to implement the functionality that the application developer needs. The WG will, however, actively liaise with relevant grid-middleware groups within the GGF.
The WG will continue to identify projects outside GGF with similar API-focus and goals, and will seek their input in the development of the API and its implementation. The WG will provide detailed non-normative examples and 'cook-books' showing how the specified APIs could be used.
Exit Strategy: --------------
The group will finish its work after the publication of the API Specification as GGF standard recommendation, accompanied by documents for API language bindings.
Goals: ------
The SAGA-CORE-WG is the first WG spawned by the SAGA-RG, which produced the informational document ("SAGA Use-Case Document, version 1"), and is producing a related requirements document.
The main goal of the WG is the creation of an API specification for the functional areas defined in these documents and explored by the first SAGA-RG design team, as listed above. This API will be submitted to GGF as a standard recommendation. The WG will produce the following documents:
* Informational Document: "Abstract SAGA-CORE-API Specification" The initial SAGA API specification in SIDL, which is language neutral.
* Recommendation documents: Language bindings for the "Abstract SAGA-CORE-API" specification These will be for a number of languages, such as C, C++, Java and Fortran.
Milestones: -----------
GGF16: - SAGA API Specification pre-v1.0
GGF17: - Submission of abstract SAGA API Specification v1.0 - Implementation details review.
GGF19: - Present Draft Language Bindings (C/C++/Java/Fortran)
-- "So much time, so little to do..." -- Garfield
Can an abstract API in SIDL be a recommendation ? On Thu, 9 Feb 2006, Andre Merzky wrote:
Hi Tom,
* Informational Document: "Abstract SAGA-CORE-API Specification" The initial SAGA API specification in SIDL, which is language neutral.
I think that should be recommendation document - that was the goal behind the whole exercise of bit flipping :-)
Cheers, Andre.
Yes, its an API specification. A. Quoting [Tom Goodale] (Feb 09 2006):
Date: Thu, 9 Feb 2006 10:00:31 -0600 (CST) From: Tom Goodale
To: saga-rg@ggf.org Subject: Re: [saga-rg] SAGA-CORE-WG charter revision 2 Can an abstract API in SIDL be a recommendation ?
On Thu, 9 Feb 2006, Andre Merzky wrote:
Hi Tom,
* Informational Document: "Abstract SAGA-CORE-API Specification" The initial SAGA API specification in SIDL, which is language neutral.
I think that should be recommendation document - that was the goal behind the whole exercise of bit flipping :-)
Cheers, Andre.
-- "So much time, so little to do..." -- Garfield
Yes, its an API specification.
Can an abstract API in SIDL be a recommendation ?
I would say not. We had this discussion in OGSA-WG with the BES (and ByteIO) work. A SIDL is not a normative description of the interface, unless there is defined mechanism for mapping from SIDL to a language binding. The conversation we had on the telecon indicated that SAGA-RG would not be producing a defined mapping mechanism, hence the need for the language bindings to be the bit that is standardised. Having a standards track SIDL and standards track binding seems an overkill. Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Director, Open Middleware Infrastructure Institute-UK (OMII-UK) c/o Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK
Well, we had that discussion before in the group, and came to the result that is should be a standard. I checked the mailing list, this was discussed in 2003 already. Actually, the agreement once was, IIRC, to have a language independedn spec, with language bindings as appendix. We later thought that the doc gets too long, and also delayed by the bindings, we split that up: language independend spec, informal bindings. Later someone proposed to do the bindings as specs as well, to give them more weight, and people did not care either way too much. I can dig out the old notes and mails if that is of interest, but I think we should not reopen too many issues over and over again, once they have been settled - we are running circles otherwise... my 2 cent, Andre. Quoting [Steven Newhouse] (Feb 09 2006):
Yes, its an API specification.
Can an abstract API in SIDL be a recommendation ?
I would say not. We had this discussion in OGSA-WG with the BES (and ByteIO) work. A SIDL is not a normative description of the interface, unless there is defined mechanism for mapping from SIDL to a language binding. The conversation we had on the telecon indicated that SAGA-RG would not be producing a defined mapping mechanism, hence the need for the language bindings to be the bit that is standardised.
Having a standards track SIDL and standards track binding seems an overkill.
Steven
-- "So much time, so little to do..." -- Garfield
participants (3)
-
Andre Merzky
-
Steven Newhouse
-
Tom Goodale