+1 for CPI and the lazy consensus
On Mon, Jan 27, 2014 at 11:10 AM, Suresh Marru <[email protected]> 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 <[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 > >>>>>>> > >>>>>>> > >>> > > > >
