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