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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>> >>>>>> >>
