Jeff, You are on track... albiet taking us to a new feature topic too ;-)
On Thu, Mar 3, 2011 at 10:22 AM, Jeffrey Trimble <[email protected]> wrote: > Comments from someone who doesn't program much (anymore, save 370 Assembler > on an IBM Mainframe!) > > Finally! I understand all of this from Mark Diggory and Mark Wood has made > it much easier by asking the questions I > had without sounding like a dummy. > > The dialogue of the message below needs to be codified into some type of > FAQ that would assist many of the people > "in the trenches" with the question "what does this mean for me?" and "How > will I be affected". > Getting some of these concepts into a FAQ would be a great direction to getting better understanding and common direction outlined within the community. Right now the best I can do is to work to dispel the FUD in the community by drafting this stuff in the wiki. I am all for others taking this and consolidating, labeling or otherwise organizing links to it to enhance find-ability. I'm also hoping to generate DSUG activities at OR11 around this work. It seems, correct me if I'm wrong, this should make the dspace.cfg and other > cfg files go away in favor of a database approach > for all configuration, including the need to get away from command line > running of ant update, correct? (Or at least it could > run in the background). > Yes, I would really like to see a DSpaceConfigurationService implemented that was database backed rather than backed by a config file, creating this would most likely be a project focused on much more (ie creating the database tables, domain objects and Administrative interfaces that allow us to edit the configuration from the browser, and GSoC comes to mind as a good target. Maybe one of the requirements in the process of getting rid of ConfigurationManager itself. There are a some key points the developers need to consider 1.) how/where the Database connection is configured 2.) how much do we allow to be gotten from the database as configuration 3.) Does the DSpace application update directly from the DB changes without having to reload the webapp context (something ConfigurationService does support when the code depending on it properly implements and registers a listener to the service). And yes, in terms of getting to the point where less configuration is stored in files, we reach a point where new cleaner deployment strategies can emerge. > Does this also mean that mean of the configurations and services we have in > DSpace can be accessed via the web instead of > at the CLI? If so, all the more to say "Go for it Mark(s)". > As based on the dialog that happened in yesterdays meeting. It sounded like Stuart and Kim were very excited about migrating much of the Filtermedia and checksum checking into curation tools. My point in presenting this here is to inform those developers on the Best Practice towards achieving a uniform restructuring. Right now Curation still takes the design approach of defining its own configuration files and relying on the PluginManager to achieve "Application Configuration", and I'm challenging that if we migrate everything to use its interface instead. We are still commiting the same design offenses that the new architecture is trying to get developers to stop doing. Please educate me if I'm totally off the trodden path, otherwise, you've got > one more fan for DSpace Services. > Thanks for the feedback, I think your spot-on. -- Mark R. Diggory @mire - www.atmire.com 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Technologielaan 9 - 3001 Heverlee - Belgium
------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
