Hello all, As discussed in our skype weekly, the definitions are now final. We didn’t change the word component, and changed RDPC to 'platform component'. By choosing for this terminology, we will have some issues with overlapping usage of the word component, hopefully not too much. Hans Bossenbroek will check the rest of the terminology list on the Wiki page for inconsistencies with the 'base definitions'. For our formal terminology list, see: http://www.amdatu.org/confluence/display/Amdatu/Terminology
Martijn GX Software | Martijn van Berkum | CTO | Wijchenseweg 111 | 6538 SW Nijmegen | The Netherlands | T +31(0)24 - 388 82 61 | F +31(0)24 - 388 86 21 | M +31(0)6 – 15 05 85 53 | [email protected] | www.gxsoftware.com<http://www.gxsoftware.com/> | twitter.com/GXSoftware<http://twitter.com/GXSoftware> | <http://twitter.com/GXSoftware> twitter.com/<twitter.com/njitram>njitram<twitter.com/njitram> From: Marcel Offermans <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Wed, 12 Oct 2011 10:58:33 +0200 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Amdatu-developers] Amdatu Terminology Hello Martijn, On Oct 11, 2011, at 14:17 , Martijn van Berkum wrote: Weaknessed or to be discussed parts in this definition: * I replaced composite with the term component. After looking up the defintion of composite, it was stated that a composite consists of a distinct set of components, which is, I guess, the word we were searching for (composite as a word is flawed as this is the result of combining those 'components', not the 'lego building blocks' we meant it to be). I'm not in favor of using the term component, because a "component" in our implementation code, which uses the Dependency Manager, refers to "something" that has dependencies on services, configuration or whatever and that might or might not publish an API (either an OSGi service, a REST service, or both). Having two things named "component" sounds too confusing. Approaching this bottom up in code we already have: - inherited from Java: classes and interfaces, which are grouped into packages - inherited from Dependency Manager: components, which are declared and can be introspected, and have dependencies and publish services - inherited from OSGi: bundles, which are our "modules" and most fine-grained way of composing applications - inherited from Apache ACE: we have artifacts (which can be bundles, configuration files or pretty much and type of deployable) which we group into features, and features again are grouped into distributions Granted, all of these are still quite technical and low level, but still I would like to at least not reuse any of these terms in a different, inconsistent way. We could re-use "feature" or "distribution" (tbh, probably a "cloud component/composite" could end up as a "distribution" in ACE, and we would assemble those from "features" in ACE (which more or less could be mapped onto (sub)projects of Amdatu, maybe a bit more fine grained (as some projects really consist of more than one set of artifacts, such as the Amdatu Identity stuff we discussed, which has features that go on a "server" and things that go on a "client". Also, after giving it some thought, I'm not sure I like the fact that we define a component/composite as something that's "most cost effective". Going back to the theories behind modularity, there are several constraints the determine the "best" way to modularize a system. Cost is one of them, but there are others, such as low coupling, high cohesion, similar rates of change, etc. I feel we should be a bit more formal here and recognize all of those constraints (or not mention any in high level texts). * RPDC is a completely new term, even an abbreviation, which is risky, I would like to have a more recognizable term Yeah, still thinking about this one. Somehow I feel we need to map this one on one or more of the technical terms I mentioned above. Greetings, Marcel _______________________________________________ Amdatu-developers mailing list [email protected]<mailto:[email protected]> http://lists.amdatu.org/mailman/listinfo/amdatu-developers
_______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
