On Wednesday 24 September 2003 21:07, Stephen McConnell wrote: > Instead of looking at this magic occuring in the agency relative to a > static set of preferences,its easier to think of this as an interaction > between a container (on the client machine) (that holds a *lot* of > context), the user (if necessary), a product profile referencing > deployment criteria, directives, configurations, etc. (on the server), > and a persistent store holding product install information together with > user preferences. > > Solutions could be assembled on the server (agency) in much the same way > that we compose component deployment solutions today (in the client > container) - by using a very small about of user supplied information, > applying/leveraging product descriptors, and matching/resolving these > relative to candidates established by the container.
Ok, still very abstract (I'm like Leo - concrete code say a lot) and may not fully grasp the implications of what you are outlining above. > >1. Whatever "user preferences" you can dream up, they are probably not > > needed by the component. > > My experience is the contary. I have several products running here on > my machine. The actual configuration info used across thse products is > remarkable similar. Keep in mind that I'm benefiting from all of the > configuration management available in Merlin - typically the actual > configuration data that needs to be changed is really small. Furthermore > - its remarkable similar in terms of root information - e.g. host names, > authentication criteria, etc. Could this be related to that you are involved with a particular "type" of applications? For instance, our components under development have a slightly larger "span of scope". AlarmService - configuration deals with common attributes (meta-data if you like) of alarm points, priority of threads running the service and not much more. TimingFactory - configuration deals with global schedules (Holidays, Working hours) and not much else. SerialDevice - configuration deals with which external devices are connected, what each of these devices capabilities are, the priority of polling these, and a lot in these lines. Mailer - outgoing mail related stuff - what you are more accustomed to. I think you get the point... Now, instead of rejecting your ideas, let's move forward... If the components could expose what they expect, and that information could be collected by tools on behalf of the Agency, I think both's needs are satisfied. I.e. Once the assembly is completed, the "Agency" would know what configuration information is required, and could "ask" the "user" for the details, and fill in "last time values" as defaults. In your case, you would have your "network stuff" (which I believe is your commonality you have seen), which may not be too extensive, whereas an assembled project in our case may request 300 parameters or more. We could then divide the "defaults" over a bunch of "users" for common similar projects. Hmmm? Maybe... > The parrallels between component composition and solutions assembly are > food for thought. Yes, indeed... > I not saying this is a good thing, but if you know in detail the > component model (including the meta info and meta data models) you can > establish and maintain very strong component contracts. I agreee that > there are parts of our specification that are sticky and others that are > just plain wobbly (e.g. selector semantics). Personally I don't find > this limiting - mainly because I stay away from sticky and wobbly areas. I just wanted to highlight that my notion of component is a much tighter entity, something like a black box with a known set of interfaces, to which it has to adhere. NOW, those interfaces are pretty loose, and I would like to see a stricter contract. When I think "component" I very much draw the parallel to more physical engineering faculties, let's say plumbing. A steel pipe is not useful if there is no datasheet, or if it couldn't be measured, not bent, not welded and so on. > So - yes - there is room for improvement - and - no - what we have is > more than sufficient. Maybe. > In fact I think that the notions I'm talking about and the things you > describing > above (and in some of your prev. posts) share a comon requirement for a > product > meta model. At the same time our repective > aims/ideas/functional-objectives are > very different. Probably. I have productivity and ensured quality in mind, and don't mind getting certain limitations imposed if it is required to gain that. Others may think differently. > Even so, one should not necessarily negate the other ;-). Not at all... Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
