Leo: At the risk of sticking my oar into the moving waters :-)....
> The problem is this: Suppose we do a very very simple container. > > Now, do you add features to it? Yes. And making using them completely optional. E.g. you don't specify configuration for the advanced features, they just don't get in your way. If you do specify them, they work for you. > If you do, you increase complexity and the container is not simple > any more. The container is not simple, it is sophisticated. But using it can be *very* simple, as you just ignore the clearly documented advanced functionality. > If you don't, all developers will do so individually in their own > projects and you have duplication of effort. > > So what do you do? Suppose you add features. > > As the container gets more and more feature rich, it is harder and > harder to get started with it (higher barrier of entry) - assembly > descriptors, metainfo, etc. etc. Whoa. Why? Can't you simply say that if you hand it the super simple version of the config info, it operates just with that (with the advanced capabilities simply inactive). Then barrier to entry is still low, yet you still have only a single codebase. > At the same time, those same assembly > descriptors are required by users of the container to avoid duplication > of code, and above all, when you know how to use them, they *increase* > simplicity. > > So what is simple for a beginner may be a nightmare of complexity > for the person building a BIG application with Avalon. What is simple > for the seasoned developer and scales well may seem like a monster > of complexity for the beginner. Don't get me wrong, I'm only observing here - I've not tried writing a container on my own yet, so what I'm saying might not be feasible. But if it's not, I haven't yet heard why not, that's all. > The three-container solution was to have one container that was easy to > start with. Then, as the user felt a need for more complexity - more > features > in the container - he could switch to the next more powerful container > instead of introducing feature creep. Don't you find people tend not to switch, though? It's tempting to stick with what you know. With the one-container approach, you can just start using more as you find you need more. > The components would still work, > but there would be a bit more complexity for the user to deal with in > exchange for more container features. A bit more committment to the > Avalon way of doing things in exchange for more magic in the container. > > And to this comes the committment threshold. As you start using metainfo > and everything, you committ your app more and more to the Avalon way of > creating applications. Maybe that isn't possible. Maybe you can not > fulfill the requirements a sophisticated container puts on your system > design. Again, the simplest of the three containers would come with > minimum requirements (no assembly spec required, etc...). As long as all the more advanced features are *optional*, it should be just as simple as the proposed Tweety, yet have the capabilities of Phoenix+, when you turn 'em on. No question that the one-size-fits-all container would *internally* be quite complex. But then again a J2EE server is a pretty complex beast, and most people don't ever want to see the insides of it... > So let me ask you - how would you solve this problem? I know you weren't asking me :-), but there's my thoughts on how to go about it. Mike JGlobal Ltd. http://www.jglobalonline.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
