Hi Richard, Thanks for the feedback. I am looking forward to your comments.
Enjoy ApacheCon! Regards Felix On 6/27/06, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Hey Felix, FYI: I am at ApacheCon right now and will take a look at this next week after I return...just didn't want you to think that I was ignoring it. -> richard Felix Meschberger wrote: > HI again, > > Based upon your recommendations, I tried to implement the abstract > BundleCache and BundleArchive strategy as a prototype. > > I have not cleaned it up properly and there is in fact one problem > with it: The BundleArchive constructors initiliaze the instances. When > extending the BundleArchive for storage dependent implementations, the > constructors of the base class do not yet know anything about the > storage, but initialization depends on the storage. My solution is to > introduce an init() method, which initializes and ist called by the > BundleCache. > > I do not like this implementation very much as it kind of transfers > responsibility for additional intialization to the caller. But in the > short time, I did not come up with a better solution. > > I attach the patch for this prototype along with the File based > implementation. > > What do you think: Could this be a way to go ? Should I post a Jira > issue ? > > Regards and Thanks > Felix, the person :-) > > On 6/20/06, Richard S. Hall <[EMAIL PROTECTED]> wrote: >> Felix Meschberger wrote: >> > On 6/20/06, Richard S. Hall <[EMAIL PROTECTED]> wrote: >> >> In general, any solution for doing stuff like you have suggested, I >> >> would hope, should concentrate on using/improving these existing >> >> mechanisms rather than creating new ones. >> > >> > I definitely agree. Yet not being able to ammend BundleCache and >> > BundleArchive, I am still required to have file system space - this >> > sort of worries me. >> >> This is the sort of stuff that we can improve upon then. I am not >> against making it once again possible to be able configure which >> implementation of BundleCache to use. It was just removed because I had >> no valid use case. We just need to discuss what is needed and how to >> do it. >> >> -> richard >>
