At 10:06 21/2/01 -0500, Geir Magnusson Jr. wrote:
>The way I hope, it is *used* by a framework, not *part of* a framework.
>
>Hopefully, down at the bottom, there is still a useful DBCP that stands
>on it's own. I know there is no standard interface for a DBCP except
>that they seem best when you don't know they are there : they look like
>a Driver.
good - the answer I was hoping for. The only issue remaining is that that
is going to require a LOT of work - to keep from people taking short cuts
and integrating it with a config/services/environment framework we are
going to need some very tuff thought police ;) The reason being that it is
damn hard to do that and as yet I have only seen one set of components that
could do that ;)
>Maybe what this does is have the DBCP provide hooks to work with larger
>scale entities. I dunno. I can't see that far. This sounds like stuff
>someone already knows, or we will find out through doing. I would
>prefer to see this shot down if 'someone knows'.
Theres a few ways of doing it - most of them are covered in standard texts
ala Design Patterns by GoF. I have been working on components of these
types for a whiel so we should be able to kick the tyres and light the
fires ;)
>> We need to define clearly wear the difference between this project is and
>> where Avalon is.
>
>Sure. But it seems to me we just went full circle and are back to
>considering Avalon as a framework again. Ohh, head hurts, head hurts :)
Ahh but the mystery of Avalon is that it is about 5 different things and
one name may refer to different bits of it - depending on the use ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
