> From: Peter Donald [mailto:[EMAIL PROTECTED]] > > Hi, > > I am not sure that this would really be useful. A few reasons; > > Using the "Services JAR specification" is really misusing it > as it is meant to > be a way to map implementations for services.
And that is what I was intending. I.e. I have a new service (component): org.dhaven.myexample.Echo In my JAR I have three implementations, but in another JAR I might have another three. Using the Services JAR specification, I can detect all my possibilities for my system. I see that as using it properly. Using it improperly, you can have a "services.list" file to list all the interface names that we can pull from the Services spec. However, I get the feeling you would not like that. Truth be told, the "assembly" file tells us what the critical services are, and we can determine the rest by using the Services JAR Specification properly. > Lifestyles are an artificial artifact that don't really need > to be defined > this way. i.e. It needs to be flexible enough to have > lifestyles like "by > default I am transient, between 3-6 on Friday I pool". Ok. So we need to agree on how to describe them. Remember that for ME we need a lowest common denominator for the base, with an additional set of options when we have a more powerful ME environment. > It would be far better to try to write a flexible > architecture rather than > trying to gaffa tape one together out of components. All I am doing is trying to come up with some minimal requirements so that we can move forward on the ME edition. As we feel that ME is done, we can move toward SE which has much more flexibility. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
