You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by Suresh Marru <sm...@apache.org> on 2014/01/23 20:41:35 UTC
Rename SPI explicitly
Hi All,
We have been overloading the use of the term API within Airavata. We discussed this few time, but how about we take an action and rename the internal component level interfaces to SPI and retain the use of API for only the external facing public API.
I am suggesting the following:
We will have Airavata API grouped by functionality (as it is today with may be minor enhancements): Application Catalog (application interface, application deployment and host descriptions), User Management, Security Credential Management, Execution Management & Metadata and Provenance Management.
For now leave the messaging system as a API as it can be called upon by external clients.
For SPI:
Orchestrator SPI
Workflow Interpreter SPI
GFac SPI
Registry SPI
Credential Store SPI
If we all agree to change this, I am willing to do the dirty work of changing the namespaces and such and bring the code to a build able stage. But that will require a code freeze for few hours.
Suresh
Re: Rename SPI explicitly
Posted by Saminda Wijeratne <sa...@gmail.com>.
+1 for CPI and the lazy consensus
On Mon, Jan 27, 2014 at 11:10 AM, Suresh Marru <sm...@apache.org> wrote:
> +1 for CPI.
>
> Can we call a lazy consensus on this change and move foreword?
>
> API also can also be used for pun to say it is the Airavata Programming
> Interface :)
>
> Suresh
>
> On Jan 27, 2014, at 1:53 PM, Marlon Pierce <ma...@iu.edu> wrote:
>
> > No major objections, but how about Component Programming Internface so
> > that we have API, SPI and CPI?
> >
> >
> > Marlon
> >
> > On 1/27/14 1:51 PM, Suresh Marru wrote:
> >> If the preference is to reserve SPI for Extensible Airavata Components,
> I like the Component Services and Component Service Interfaces to name the
> current internal API’s. Hoping this will not raise eye brows of former
> CORBA developers.
> >>
> >> Suresh
> >>
> >> On Jan 25, 2014, at 8:20 PM, Saminda Wijeratne <sa...@gmail.com>
> wrote:
> >>
> >>> I fully agree with both Marlons' and Sureshs' arguments. We should
> just pick a name and move on for now atleast to get things moving. What if
> we just call them Component Services? or Component Service Interfaces? just
> a thought.
> >>>
> >>> A small clarification for anyone who is not familiar with current
> Airavata impl: I like the name of SPI so that we can use it someday for
> "Airavata Developer Guide" (not "Gateway Developer Guide"). At the moment
> both Orchestrator and Registry interface SPIs correspond to the interfaces
> that gets exposed to external components as well. Thus the same SPI becomes
> sort of an internal API as well. But the SPIs defined for GFac Providers
> Workflow Interpreter and I think Credential store is not necessarily what
> the external component developers see when they want to use those
> components. i.e. those SPI interfaces are hidden to external component devs.
> >>>
> >>> Regards,
> >>> Saminda
> >>>
> >>>
> >>> On Sat, Jan 25, 2014 at 7:27 AM, Suresh Marru <sm...@apache.org>
> wrote:
> >>> I fully agree with Saminda’s clarification and if there is a better
> naming convention it will be better to follow it. Technically speaking
> current internal and external airavata interfaces are API’s but we clearly
> have to disambiguate them.
> >>>
> >>> Lets see if any one comes up with a better naming convention, if not
> will just cook up a justification to move on.
> >>>
> >>> The definition at [1] defines SPI as to be intended to be implemented
> or extended by a third party. Clearly the extending components by external
> developers is not our scenario, but we implementing an interface fits.
> Further the software engineering institute paper [2] discusses SPI’s as an
> abstraction to replaceable components, this is clearly our use case. We
> want registry, gfac, orchestrator, workflow interpreter to have SPI whose
> implementation can be completely replaces as long as the SPI integrated
> with rest of the system remains the same.
> >>>
> >>> Suresh
> >>> [1] - http://en.wikipedia.org/wiki/Service_provider_interface
> >>> [2] -
> http://resources.sei.cmu.edu/asset_files/TechnicalNote/2002_004_001_13958.pdf
> >>>
> >>> On Jan 24, 2014, at 4:16 PM, Marlon Pierce <ma...@iu.edu> wrote:
> >>>
> >>>> My understanding: For now, we use the term SPI to refer to the
> internal
> >>>> "public" interface that one Airavata component (say, the registry)
> >>>> exposes to other Airavata components. This is corresponds to
> Saminda's
> >>>> developer group #1. In the future, we may formalize these interfaces
> in
> >>>> Thrift. Then this could be useful for developers in Saminda's group
> #2.
> >>>>
> >>>> This isn't the classic usage of SPI, as Saminda points out. Is there a
> >>>> better term we should use?
> >>>>
> >>>> Marlon
> >>>>
> >>>> On 1/24/14 3:10 PM, Saminda Wijeratne wrote:
> >>>>> All the above components correspond to 2 developer parties that
> could work
> >>>>> on them. One set of developers will be using those components to do
> some
> >>>>> task while the 2nd set of developers will be implementing the
> interfaces of
> >>>>> those components to extend the component functionalities. IMO the
> word SPI
> >>>>> makes more sense only for the latter set of developers. Am I to
> understand
> >>>>> that the renaming is for these developers only?
> >>>>>
> >>>>>
> >>>>> On Fri, Jan 24, 2014 at 11:23 AM, Marlon Pierce <ma...@iu.edu>
> wrote:
> >>>>>
> >>>>>> No discussion on this. I am +1 on the proposed API-SPI
> distinction,
> >>>>>> but I just noticed that Suresh was also suggesting some namespace
> changes.
> >>>>>>
> >>>>>>
> >>>>>> Marlon
> >>>>>>
> >>>>>> On 1/23/14 2:41 PM, Suresh Marru wrote:
> >>>>>>> Hi All,
> >>>>>>>
> >>>>>>> We have been overloading the use of the term API within Airavata.
> We
> >>>>>> discussed this few time, but how about we take an action and rename
> the
> >>>>>> internal component level interfaces to SPI and retain the use of
> API for
> >>>>>> only the external facing public API.
> >>>>>>> I am suggesting the following:
> >>>>>>>
> >>>>>>> We will have Airavata API grouped by functionality (as it is today
> with
> >>>>>> may be minor enhancements): Application Catalog (application
> interface,
> >>>>>> application deployment and host descriptions), User Management,
> Security
> >>>>>> Credential Management, Execution Management & Metadata and
> Provenance
> >>>>>> Management.
> >>>>>>> For now leave the messaging system as a API as it can be called
> upon by
> >>>>>> external clients.
> >>>>>>> For SPI:
> >>>>>>> Orchestrator SPI
> >>>>>>> Workflow Interpreter SPI
> >>>>>>> GFac SPI
> >>>>>>> Registry SPI
> >>>>>>> Credential Store SPI
> >>>>>>>
> >>>>>>> If we all agree to change this, I am willing to do the dirty work
> of
> >>>>>> changing the namespaces and such and bring the code to a build able
> stage.
> >>>>>> But that will require a code freeze for few hours.
> >>>>>>> Suresh
> >>>>>>>
> >>>>>>>
> >>>
> >
>
>
Re: Rename SPI explicitly
Posted by Suresh Marru <sm...@apache.org>.
+1 for CPI.
Can we call a lazy consensus on this change and move foreword?
API also can also be used for pun to say it is the Airavata Programming Interface :)
Suresh
On Jan 27, 2014, at 1:53 PM, Marlon Pierce <ma...@iu.edu> wrote:
> No major objections, but how about Component Programming Internface so
> that we have API, SPI and CPI?
>
>
> Marlon
>
> On 1/27/14 1:51 PM, Suresh Marru wrote:
>> If the preference is to reserve SPI for Extensible Airavata Components, I like the Component Services and Component Service Interfaces to name the current internal API’s. Hoping this will not raise eye brows of former CORBA developers.
>>
>> Suresh
>>
>> On Jan 25, 2014, at 8:20 PM, Saminda Wijeratne <sa...@gmail.com> wrote:
>>
>>> I fully agree with both Marlons' and Sureshs' arguments. We should just pick a name and move on for now atleast to get things moving. What if we just call them Component Services? or Component Service Interfaces? just a thought.
>>>
>>> A small clarification for anyone who is not familiar with current Airavata impl: I like the name of SPI so that we can use it someday for "Airavata Developer Guide" (not "Gateway Developer Guide"). At the moment both Orchestrator and Registry interface SPIs correspond to the interfaces that gets exposed to external components as well. Thus the same SPI becomes sort of an internal API as well. But the SPIs defined for GFac Providers Workflow Interpreter and I think Credential store is not necessarily what the external component developers see when they want to use those components. i.e. those SPI interfaces are hidden to external component devs.
>>>
>>> Regards,
>>> Saminda
>>>
>>>
>>> On Sat, Jan 25, 2014 at 7:27 AM, Suresh Marru <sm...@apache.org> wrote:
>>> I fully agree with Saminda’s clarification and if there is a better naming convention it will be better to follow it. Technically speaking current internal and external airavata interfaces are API’s but we clearly have to disambiguate them.
>>>
>>> Lets see if any one comes up with a better naming convention, if not will just cook up a justification to move on.
>>>
>>> The definition at [1] defines SPI as to be intended to be implemented or extended by a third party. Clearly the extending components by external developers is not our scenario, but we implementing an interface fits. Further the software engineering institute paper [2] discusses SPI’s as an abstraction to replaceable components, this is clearly our use case. We want registry, gfac, orchestrator, workflow interpreter to have SPI whose implementation can be completely replaces as long as the SPI integrated with rest of the system remains the same.
>>>
>>> Suresh
>>> [1] - http://en.wikipedia.org/wiki/Service_provider_interface
>>> [2] - http://resources.sei.cmu.edu/asset_files/TechnicalNote/2002_004_001_13958.pdf
>>>
>>> On Jan 24, 2014, at 4:16 PM, Marlon Pierce <ma...@iu.edu> wrote:
>>>
>>>> My understanding: For now, we use the term SPI to refer to the internal
>>>> "public" interface that one Airavata component (say, the registry)
>>>> exposes to other Airavata components. This is corresponds to Saminda's
>>>> developer group #1. In the future, we may formalize these interfaces in
>>>> Thrift. Then this could be useful for developers in Saminda's group #2.
>>>>
>>>> This isn't the classic usage of SPI, as Saminda points out. Is there a
>>>> better term we should use?
>>>>
>>>> Marlon
>>>>
>>>> On 1/24/14 3:10 PM, Saminda Wijeratne wrote:
>>>>> All the above components correspond to 2 developer parties that could work
>>>>> on them. One set of developers will be using those components to do some
>>>>> task while the 2nd set of developers will be implementing the interfaces of
>>>>> those components to extend the component functionalities. IMO the word SPI
>>>>> makes more sense only for the latter set of developers. Am I to understand
>>>>> that the renaming is for these developers only?
>>>>>
>>>>>
>>>>> On Fri, Jan 24, 2014 at 11:23 AM, Marlon Pierce <ma...@iu.edu> wrote:
>>>>>
>>>>>> No discussion on this. I am +1 on the proposed API-SPI distinction,
>>>>>> but I just noticed that Suresh was also suggesting some namespace changes.
>>>>>>
>>>>>>
>>>>>> Marlon
>>>>>>
>>>>>> On 1/23/14 2:41 PM, Suresh Marru wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> We have been overloading the use of the term API within Airavata. We
>>>>>> discussed this few time, but how about we take an action and rename the
>>>>>> internal component level interfaces to SPI and retain the use of API for
>>>>>> only the external facing public API.
>>>>>>> I am suggesting the following:
>>>>>>>
>>>>>>> We will have Airavata API grouped by functionality (as it is today with
>>>>>> may be minor enhancements): Application Catalog (application interface,
>>>>>> application deployment and host descriptions), User Management, Security
>>>>>> Credential Management, Execution Management & Metadata and Provenance
>>>>>> Management.
>>>>>>> For now leave the messaging system as a API as it can be called upon by
>>>>>> external clients.
>>>>>>> For SPI:
>>>>>>> Orchestrator SPI
>>>>>>> Workflow Interpreter SPI
>>>>>>> GFac SPI
>>>>>>> Registry SPI
>>>>>>> Credential Store SPI
>>>>>>>
>>>>>>> If we all agree to change this, I am willing to do the dirty work of
>>>>>> changing the namespaces and such and bring the code to a build able stage.
>>>>>> But that will require a code freeze for few hours.
>>>>>>> Suresh
>>>>>>>
>>>>>>>
>>>
>
Re: Rename SPI explicitly
Posted by Marlon Pierce <ma...@iu.edu>.
No major objections, but how about Component Programming Internface so
that we have API, SPI and CPI?
Marlon
On 1/27/14 1:51 PM, Suresh Marru wrote:
> If the preference is to reserve SPI for Extensible Airavata Components, I like the Component Services and Component Service Interfaces to name the current internal API’s. Hoping this will not raise eye brows of former CORBA developers.
>
> Suresh
>
> On Jan 25, 2014, at 8:20 PM, Saminda Wijeratne <sa...@gmail.com> wrote:
>
>> I fully agree with both Marlons' and Sureshs' arguments. We should just pick a name and move on for now atleast to get things moving. What if we just call them Component Services? or Component Service Interfaces? just a thought.
>>
>> A small clarification for anyone who is not familiar with current Airavata impl: I like the name of SPI so that we can use it someday for "Airavata Developer Guide" (not "Gateway Developer Guide"). At the moment both Orchestrator and Registry interface SPIs correspond to the interfaces that gets exposed to external components as well. Thus the same SPI becomes sort of an internal API as well. But the SPIs defined for GFac Providers Workflow Interpreter and I think Credential store is not necessarily what the external component developers see when they want to use those components. i.e. those SPI interfaces are hidden to external component devs.
>>
>> Regards,
>> Saminda
>>
>>
>> On Sat, Jan 25, 2014 at 7:27 AM, Suresh Marru <sm...@apache.org> wrote:
>> I fully agree with Saminda’s clarification and if there is a better naming convention it will be better to follow it. Technically speaking current internal and external airavata interfaces are API’s but we clearly have to disambiguate them.
>>
>> Lets see if any one comes up with a better naming convention, if not will just cook up a justification to move on.
>>
>> The definition at [1] defines SPI as to be intended to be implemented or extended by a third party. Clearly the extending components by external developers is not our scenario, but we implementing an interface fits. Further the software engineering institute paper [2] discusses SPI’s as an abstraction to replaceable components, this is clearly our use case. We want registry, gfac, orchestrator, workflow interpreter to have SPI whose implementation can be completely replaces as long as the SPI integrated with rest of the system remains the same.
>>
>> Suresh
>> [1] - http://en.wikipedia.org/wiki/Service_provider_interface
>> [2] - http://resources.sei.cmu.edu/asset_files/TechnicalNote/2002_004_001_13958.pdf
>>
>> On Jan 24, 2014, at 4:16 PM, Marlon Pierce <ma...@iu.edu> wrote:
>>
>>> My understanding: For now, we use the term SPI to refer to the internal
>>> "public" interface that one Airavata component (say, the registry)
>>> exposes to other Airavata components. This is corresponds to Saminda's
>>> developer group #1. In the future, we may formalize these interfaces in
>>> Thrift. Then this could be useful for developers in Saminda's group #2.
>>>
>>> This isn't the classic usage of SPI, as Saminda points out. Is there a
>>> better term we should use?
>>>
>>> Marlon
>>>
>>> On 1/24/14 3:10 PM, Saminda Wijeratne wrote:
>>>> All the above components correspond to 2 developer parties that could work
>>>> on them. One set of developers will be using those components to do some
>>>> task while the 2nd set of developers will be implementing the interfaces of
>>>> those components to extend the component functionalities. IMO the word SPI
>>>> makes more sense only for the latter set of developers. Am I to understand
>>>> that the renaming is for these developers only?
>>>>
>>>>
>>>> On Fri, Jan 24, 2014 at 11:23 AM, Marlon Pierce <ma...@iu.edu> wrote:
>>>>
>>>>> No discussion on this. I am +1 on the proposed API-SPI distinction,
>>>>> but I just noticed that Suresh was also suggesting some namespace changes.
>>>>>
>>>>>
>>>>> Marlon
>>>>>
>>>>> On 1/23/14 2:41 PM, Suresh Marru wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> We have been overloading the use of the term API within Airavata. We
>>>>> discussed this few time, but how about we take an action and rename the
>>>>> internal component level interfaces to SPI and retain the use of API for
>>>>> only the external facing public API.
>>>>>> I am suggesting the following:
>>>>>>
>>>>>> We will have Airavata API grouped by functionality (as it is today with
>>>>> may be minor enhancements): Application Catalog (application interface,
>>>>> application deployment and host descriptions), User Management, Security
>>>>> Credential Management, Execution Management & Metadata and Provenance
>>>>> Management.
>>>>>> For now leave the messaging system as a API as it can be called upon by
>>>>> external clients.
>>>>>> For SPI:
>>>>>> Orchestrator SPI
>>>>>> Workflow Interpreter SPI
>>>>>> GFac SPI
>>>>>> Registry SPI
>>>>>> Credential Store SPI
>>>>>>
>>>>>> If we all agree to change this, I am willing to do the dirty work of
>>>>> changing the namespaces and such and bring the code to a build able stage.
>>>>> But that will require a code freeze for few hours.
>>>>>> Suresh
>>>>>>
>>>>>>
>>
Re: Rename SPI explicitly
Posted by Suresh Marru <sm...@apache.org>.
If the preference is to reserve SPI for Extensible Airavata Components, I like the Component Services and Component Service Interfaces to name the current internal API’s. Hoping this will not raise eye brows of former CORBA developers.
Suresh
On Jan 25, 2014, at 8:20 PM, Saminda Wijeratne <sa...@gmail.com> wrote:
> I fully agree with both Marlons' and Sureshs' arguments. We should just pick a name and move on for now atleast to get things moving. What if we just call them Component Services? or Component Service Interfaces? just a thought.
>
> A small clarification for anyone who is not familiar with current Airavata impl: I like the name of SPI so that we can use it someday for "Airavata Developer Guide" (not "Gateway Developer Guide"). At the moment both Orchestrator and Registry interface SPIs correspond to the interfaces that gets exposed to external components as well. Thus the same SPI becomes sort of an internal API as well. But the SPIs defined for GFac Providers Workflow Interpreter and I think Credential store is not necessarily what the external component developers see when they want to use those components. i.e. those SPI interfaces are hidden to external component devs.
>
> Regards,
> Saminda
>
>
> On Sat, Jan 25, 2014 at 7:27 AM, Suresh Marru <sm...@apache.org> wrote:
> I fully agree with Saminda’s clarification and if there is a better naming convention it will be better to follow it. Technically speaking current internal and external airavata interfaces are API’s but we clearly have to disambiguate them.
>
> Lets see if any one comes up with a better naming convention, if not will just cook up a justification to move on.
>
> The definition at [1] defines SPI as to be intended to be implemented or extended by a third party. Clearly the extending components by external developers is not our scenario, but we implementing an interface fits. Further the software engineering institute paper [2] discusses SPI’s as an abstraction to replaceable components, this is clearly our use case. We want registry, gfac, orchestrator, workflow interpreter to have SPI whose implementation can be completely replaces as long as the SPI integrated with rest of the system remains the same.
>
> Suresh
> [1] - http://en.wikipedia.org/wiki/Service_provider_interface
> [2] - http://resources.sei.cmu.edu/asset_files/TechnicalNote/2002_004_001_13958.pdf
>
> On Jan 24, 2014, at 4:16 PM, Marlon Pierce <ma...@iu.edu> wrote:
>
> > My understanding: For now, we use the term SPI to refer to the internal
> > "public" interface that one Airavata component (say, the registry)
> > exposes to other Airavata components. This is corresponds to Saminda's
> > developer group #1. In the future, we may formalize these interfaces in
> > Thrift. Then this could be useful for developers in Saminda's group #2.
> >
> > This isn't the classic usage of SPI, as Saminda points out. Is there a
> > better term we should use?
> >
> > Marlon
> >
> > On 1/24/14 3:10 PM, Saminda Wijeratne wrote:
> >> All the above components correspond to 2 developer parties that could work
> >> on them. One set of developers will be using those components to do some
> >> task while the 2nd set of developers will be implementing the interfaces of
> >> those components to extend the component functionalities. IMO the word SPI
> >> makes more sense only for the latter set of developers. Am I to understand
> >> that the renaming is for these developers only?
> >>
> >>
> >> On Fri, Jan 24, 2014 at 11:23 AM, Marlon Pierce <ma...@iu.edu> wrote:
> >>
> >>> No discussion on this. I am +1 on the proposed API-SPI distinction,
> >>> but I just noticed that Suresh was also suggesting some namespace changes.
> >>>
> >>>
> >>> Marlon
> >>>
> >>> On 1/23/14 2:41 PM, Suresh Marru wrote:
> >>>> Hi All,
> >>>>
> >>>> We have been overloading the use of the term API within Airavata. We
> >>> discussed this few time, but how about we take an action and rename the
> >>> internal component level interfaces to SPI and retain the use of API for
> >>> only the external facing public API.
> >>>> I am suggesting the following:
> >>>>
> >>>> We will have Airavata API grouped by functionality (as it is today with
> >>> may be minor enhancements): Application Catalog (application interface,
> >>> application deployment and host descriptions), User Management, Security
> >>> Credential Management, Execution Management & Metadata and Provenance
> >>> Management.
> >>>> For now leave the messaging system as a API as it can be called upon by
> >>> external clients.
> >>>> For SPI:
> >>>> Orchestrator SPI
> >>>> Workflow Interpreter SPI
> >>>> GFac SPI
> >>>> Registry SPI
> >>>> Credential Store SPI
> >>>>
> >>>> If we all agree to change this, I am willing to do the dirty work of
> >>> changing the namespaces and such and bring the code to a build able stage.
> >>> But that will require a code freeze for few hours.
> >>>> Suresh
> >>>>
> >>>>
> >>>
> >
>
>
Re: Rename SPI explicitly
Posted by Saminda Wijeratne <sa...@gmail.com>.
I fully agree with both Marlons' and Sureshs' arguments. We should just
pick a name and move on for now atleast to get things moving. What if we
just call them Component Services? or Component Service Interfaces? just a
thought.
A small clarification for anyone who is not familiar with current Airavata
impl: I like the name of SPI so that we can use it someday for "Airavata
Developer Guide" (not "Gateway Developer Guide"). At the moment both
Orchestrator and Registry interface SPIs correspond to the interfaces that
gets exposed to external components as well. Thus the same SPI becomes sort
of an internal API as well. But the SPIs defined for GFac Providers
Workflow Interpreter and I think Credential store is not necessarily what
the external component developers see when they want to use those
components. i.e. those SPI interfaces are hidden to external component
devs.
Regards,
Saminda
On Sat, Jan 25, 2014 at 7:27 AM, Suresh Marru <sm...@apache.org> wrote:
> I fully agree with Saminda’s clarification and if there is a better naming
> convention it will be better to follow it. Technically speaking current
> internal and external airavata interfaces are API’s but we clearly have to
> disambiguate them.
>
> Lets see if any one comes up with a better naming convention, if not will
> just cook up a justification to move on.
>
> The definition at [1] defines SPI as to be intended to be implemented or
> extended by a third party. Clearly the extending components by external
> developers is not our scenario, but we implementing an interface fits.
> Further the software engineering institute paper [2] discusses SPI’s as an
> abstraction to replaceable components, this is clearly our use case. We
> want registry, gfac, orchestrator, workflow interpreter to have SPI whose
> implementation can be completely replaces as long as the SPI integrated
> with rest of the system remains the same.
>
> Suresh
> [1] - http://en.wikipedia.org/wiki/Service_provider_interface
> [2] -
> http://resources.sei.cmu.edu/asset_files/TechnicalNote/2002_004_001_13958.pdf
>
> On Jan 24, 2014, at 4:16 PM, Marlon Pierce <ma...@iu.edu> wrote:
>
> > My understanding: For now, we use the term SPI to refer to the internal
> > "public" interface that one Airavata component (say, the registry)
> > exposes to other Airavata components. This is corresponds to Saminda's
> > developer group #1. In the future, we may formalize these interfaces in
> > Thrift. Then this could be useful for developers in Saminda's group #2.
> >
> > This isn't the classic usage of SPI, as Saminda points out. Is there a
> > better term we should use?
> >
> > Marlon
> >
> > On 1/24/14 3:10 PM, Saminda Wijeratne wrote:
> >> All the above components correspond to 2 developer parties that could
> work
> >> on them. One set of developers will be using those components to do some
> >> task while the 2nd set of developers will be implementing the
> interfaces of
> >> those components to extend the component functionalities. IMO the word
> SPI
> >> makes more sense only for the latter set of developers. Am I to
> understand
> >> that the renaming is for these developers only?
> >>
> >>
> >> On Fri, Jan 24, 2014 at 11:23 AM, Marlon Pierce <ma...@iu.edu>
> wrote:
> >>
> >>> No discussion on this. I am +1 on the proposed API-SPI distinction,
> >>> but I just noticed that Suresh was also suggesting some namespace
> changes.
> >>>
> >>>
> >>> Marlon
> >>>
> >>> On 1/23/14 2:41 PM, Suresh Marru wrote:
> >>>> Hi All,
> >>>>
> >>>> We have been overloading the use of the term API within Airavata. We
> >>> discussed this few time, but how about we take an action and rename the
> >>> internal component level interfaces to SPI and retain the use of API
> for
> >>> only the external facing public API.
> >>>> I am suggesting the following:
> >>>>
> >>>> We will have Airavata API grouped by functionality (as it is today
> with
> >>> may be minor enhancements): Application Catalog (application interface,
> >>> application deployment and host descriptions), User Management,
> Security
> >>> Credential Management, Execution Management & Metadata and Provenance
> >>> Management.
> >>>> For now leave the messaging system as a API as it can be called upon
> by
> >>> external clients.
> >>>> For SPI:
> >>>> Orchestrator SPI
> >>>> Workflow Interpreter SPI
> >>>> GFac SPI
> >>>> Registry SPI
> >>>> Credential Store SPI
> >>>>
> >>>> If we all agree to change this, I am willing to do the dirty work of
> >>> changing the namespaces and such and bring the code to a build able
> stage.
> >>> But that will require a code freeze for few hours.
> >>>> Suresh
> >>>>
> >>>>
> >>>
> >
>
>
Re: Rename SPI explicitly
Posted by Suresh Marru <sm...@apache.org>.
I fully agree with Saminda’s clarification and if there is a better naming convention it will be better to follow it. Technically speaking current internal and external airavata interfaces are API’s but we clearly have to disambiguate them.
Lets see if any one comes up with a better naming convention, if not will just cook up a justification to move on.
The definition at [1] defines SPI as to be intended to be implemented or extended by a third party. Clearly the extending components by external developers is not our scenario, but we implementing an interface fits. Further the software engineering institute paper [2] discusses SPI’s as an abstraction to replaceable components, this is clearly our use case. We want registry, gfac, orchestrator, workflow interpreter to have SPI whose implementation can be completely replaces as long as the SPI integrated with rest of the system remains the same.
Suresh
[1] - http://en.wikipedia.org/wiki/Service_provider_interface
[2] - http://resources.sei.cmu.edu/asset_files/TechnicalNote/2002_004_001_13958.pdf
On Jan 24, 2014, at 4:16 PM, Marlon Pierce <ma...@iu.edu> wrote:
> My understanding: For now, we use the term SPI to refer to the internal
> "public" interface that one Airavata component (say, the registry)
> exposes to other Airavata components. This is corresponds to Saminda's
> developer group #1. In the future, we may formalize these interfaces in
> Thrift. Then this could be useful for developers in Saminda's group #2.
>
> This isn't the classic usage of SPI, as Saminda points out. Is there a
> better term we should use?
>
> Marlon
>
> On 1/24/14 3:10 PM, Saminda Wijeratne wrote:
>> All the above components correspond to 2 developer parties that could work
>> on them. One set of developers will be using those components to do some
>> task while the 2nd set of developers will be implementing the interfaces of
>> those components to extend the component functionalities. IMO the word SPI
>> makes more sense only for the latter set of developers. Am I to understand
>> that the renaming is for these developers only?
>>
>>
>> On Fri, Jan 24, 2014 at 11:23 AM, Marlon Pierce <ma...@iu.edu> wrote:
>>
>>> No discussion on this. I am +1 on the proposed API-SPI distinction,
>>> but I just noticed that Suresh was also suggesting some namespace changes.
>>>
>>>
>>> Marlon
>>>
>>> On 1/23/14 2:41 PM, Suresh Marru wrote:
>>>> Hi All,
>>>>
>>>> We have been overloading the use of the term API within Airavata. We
>>> discussed this few time, but how about we take an action and rename the
>>> internal component level interfaces to SPI and retain the use of API for
>>> only the external facing public API.
>>>> I am suggesting the following:
>>>>
>>>> We will have Airavata API grouped by functionality (as it is today with
>>> may be minor enhancements): Application Catalog (application interface,
>>> application deployment and host descriptions), User Management, Security
>>> Credential Management, Execution Management & Metadata and Provenance
>>> Management.
>>>> For now leave the messaging system as a API as it can be called upon by
>>> external clients.
>>>> For SPI:
>>>> Orchestrator SPI
>>>> Workflow Interpreter SPI
>>>> GFac SPI
>>>> Registry SPI
>>>> Credential Store SPI
>>>>
>>>> If we all agree to change this, I am willing to do the dirty work of
>>> changing the namespaces and such and bring the code to a build able stage.
>>> But that will require a code freeze for few hours.
>>>> Suresh
>>>>
>>>>
>>>
>
Re: Rename SPI explicitly
Posted by Marlon Pierce <ma...@iu.edu>.
My understanding: For now, we use the term SPI to refer to the internal
"public" interface that one Airavata component (say, the registry)
exposes to other Airavata components. This is corresponds to Saminda's
developer group #1. In the future, we may formalize these interfaces in
Thrift. Then this could be useful for developers in Saminda's group #2.
This isn't the classic usage of SPI, as Saminda points out. Is there a
better term we should use?
Marlon
On 1/24/14 3:10 PM, Saminda Wijeratne wrote:
> All the above components correspond to 2 developer parties that could work
> on them. One set of developers will be using those components to do some
> task while the 2nd set of developers will be implementing the interfaces of
> those components to extend the component functionalities. IMO the word SPI
> makes more sense only for the latter set of developers. Am I to understand
> that the renaming is for these developers only?
>
>
> On Fri, Jan 24, 2014 at 11:23 AM, Marlon Pierce <ma...@iu.edu> wrote:
>
>> No discussion on this. I am +1 on the proposed API-SPI distinction,
>> but I just noticed that Suresh was also suggesting some namespace changes.
>>
>>
>> Marlon
>>
>> On 1/23/14 2:41 PM, Suresh Marru wrote:
>>> Hi All,
>>>
>>> We have been overloading the use of the term API within Airavata. We
>> discussed this few time, but how about we take an action and rename the
>> internal component level interfaces to SPI and retain the use of API for
>> only the external facing public API.
>>> I am suggesting the following:
>>>
>>> We will have Airavata API grouped by functionality (as it is today with
>> may be minor enhancements): Application Catalog (application interface,
>> application deployment and host descriptions), User Management, Security
>> Credential Management, Execution Management & Metadata and Provenance
>> Management.
>>> For now leave the messaging system as a API as it can be called upon by
>> external clients.
>>> For SPI:
>>> Orchestrator SPI
>>> Workflow Interpreter SPI
>>> GFac SPI
>>> Registry SPI
>>> Credential Store SPI
>>>
>>> If we all agree to change this, I am willing to do the dirty work of
>> changing the namespaces and such and bring the code to a build able stage.
>> But that will require a code freeze for few hours.
>>> Suresh
>>>
>>>
>>
Re: Rename SPI explicitly
Posted by Saminda Wijeratne <sa...@gmail.com>.
All the above components correspond to 2 developer parties that could work
on them. One set of developers will be using those components to do some
task while the 2nd set of developers will be implementing the interfaces of
those components to extend the component functionalities. IMO the word SPI
makes more sense only for the latter set of developers. Am I to understand
that the renaming is for these developers only?
On Fri, Jan 24, 2014 at 11:23 AM, Marlon Pierce <ma...@iu.edu> wrote:
> No discussion on this. I am +1 on the proposed API-SPI distinction,
> but I just noticed that Suresh was also suggesting some namespace changes.
>
>
> Marlon
>
> On 1/23/14 2:41 PM, Suresh Marru wrote:
> > Hi All,
> >
> > We have been overloading the use of the term API within Airavata. We
> discussed this few time, but how about we take an action and rename the
> internal component level interfaces to SPI and retain the use of API for
> only the external facing public API.
> >
> > I am suggesting the following:
> >
> > We will have Airavata API grouped by functionality (as it is today with
> may be minor enhancements): Application Catalog (application interface,
> application deployment and host descriptions), User Management, Security
> Credential Management, Execution Management & Metadata and Provenance
> Management.
> > For now leave the messaging system as a API as it can be called upon by
> external clients.
> >
> > For SPI:
> > Orchestrator SPI
> > Workflow Interpreter SPI
> > GFac SPI
> > Registry SPI
> > Credential Store SPI
> >
> > If we all agree to change this, I am willing to do the dirty work of
> changing the namespaces and such and bring the code to a build able stage.
> But that will require a code freeze for few hours.
> >
> > Suresh
> >
> >
>
>
Re: Rename SPI explicitly
Posted by Marlon Pierce <ma...@iu.edu>.
No discussion on this. I am +1 on the proposed API-SPI distinction,
but I just noticed that Suresh was also suggesting some namespace changes.
Marlon
On 1/23/14 2:41 PM, Suresh Marru wrote:
> Hi All,
>
> We have been overloading the use of the term API within Airavata. We discussed this few time, but how about we take an action and rename the internal component level interfaces to SPI and retain the use of API for only the external facing public API.
>
> I am suggesting the following:
>
> We will have Airavata API grouped by functionality (as it is today with may be minor enhancements): Application Catalog (application interface, application deployment and host descriptions), User Management, Security Credential Management, Execution Management & Metadata and Provenance Management.
> For now leave the messaging system as a API as it can be called upon by external clients.
>
> For SPI:
> Orchestrator SPI
> Workflow Interpreter SPI
> GFac SPI
> Registry SPI
> Credential Store SPI
>
> If we all agree to change this, I am willing to do the dirty work of changing the namespaces and such and bring the code to a build able stage. But that will require a code freeze for few hours.
>
> Suresh
>
>