Noel, >>Because then we'd end up having to rip off, or re-invent, a logging >>mechanism for ourselves. Which seems daft. >> >> > >Agreed. Although there is a difference between a mechanism >(implementation), and a standard interface. In the latter case, container >authors simply have to adapt the standard interface to the "native" logging >mechanism. > > > >>So the choice is either to use a logging framework which can overlay a >>number of common logging products, [or] to leave logging to the >>discretion of the writers of Mailets. >> >> > >It isn't sufficient to say take that you'll "leave logging to the discretion >of the writers of Mailets", and keep the Mailet API "clean." > >If the "writers of Mailets" lack a common INTERFACE to access logging, then >every mailet that needs access to logging will be required to be >platform-specific. > >Avalon addresses this in two cooperative parts: > > 1. Avalon Frameworks provide common interfaces that components expose > 2. Avalon containers inspect components to see what interfaces they expose, > and provide them with the services they need. > >This means that a vendor specific container can support both components that >use the platform-neutral interfaces, and components that use >platform-specific interfaces. Component authors are afforded the choice of >platform-independence or additional functionality on a >component-by-component basis. If a container does support a service, e.g., >logging, it can simply not provide that service to the component. >Configuration files can provide further refinement over runtime bindings. > >Paul will correct me, in sure, if I've gotten any points wrong. > > I'm still uneasy about your use of the word platform. I'd prefer container as platform means Win32 / unix / etc to me.
-ph -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
