airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject Re: Rename SPI explicitly
Date Sat, 25 Jan 2014 15:27:21 GMT
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 <marpierc@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 <marpierc@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
>>>> 
>>>> 
>>> 
> 


Mime
View raw message