+1 I'd be fine with duplicating "common" configs into separate 'xmlui.cfg' and 'jspui.cfg' files. We just need someone to volunteer to take that on, and then ensure XMLUI or JSPUI is tweaked as necessary to ensure it is loading the proper "common" webui configs.
-Tim On 6/29/2011 9:57 AM, Mark Diggory wrote: > I would like to see the "common" web ui config duplicated in both > jpsui.cfg and xmlui.cfg because the config is not really common, the > code using it is different in each case and in some cases the behavior > is different. It would be best not to have overlap in the ui configs > and arguing DRY in this case has limited benefit over consolidating > and separating the module configurations. Likewise, say we head to > the route of storing this config in the db, what if you decide to run > more that one web app and want to test configuration separately? You > can't because of this assumed requirement that DRY is always best > (sometimes, as we can see, it is not). > > Mark > > On Wednesday, June 29, 2011, Tim Donohue<tdono...@duraspace.org> wrote: >> >> On 6/29/2011 7:32 AM, Mark H. Wood wrote: >>> On Tue, Jun 28, 2011 at 09:16:59AM -0500, Tim Donohue wrote: >>>> A slightly larger project would be to determine whether it is possible >>>> to split out the JSPUI and XMLUI settings into separate xmlui.cfg and >>>> jspui.cfg files in /config/modules/. (This may be more difficult as >>>> there are some configs used by *both* JSPUI and XMLUI) >>> >>> Do we have any idea of how many sites run both UIs and would be >>> impacted slightly by duplicating the shared settings? >> >> Likely not many (most choose XMLUI or JSPUI, not both). However, if we >> were to go this route, we'd likely need to tweak some XMLUI/JSPUI code >> so that they no longer used the exact same setting in the exact same >> config file. In other words, we'd need to ensure that a duplicate >> setting in a new 'jspui.cfg' was not also being used by the XMLUI >> (instead, XMLUI would need to be potentially tweaked to only use >> settings from a xmlui.cfg file or similar) >> >>> >>> And would there be any problem with pulling out that huge wad of SRB >>> settings? >>> >> >> It would make sense to start pulling out larger "chunks" of settings as >> well. SRB settings is a good candidate to pull out into an >> 'storage-srb.cfg'. Packager/Crosswalk settings may be another good >> candidate to pull out into a 'packager.cfg' file. There's likely others >> as well we could pull out. >> >> I should also note that as we are doing this work, we should be aware >> that we likely will need modifications to our Documentation (especially >> the Configuration section of the Docs, though other areas may also be >> affected). >> >> I've created a new "Documentation Development" space on our Wiki. This >> is an area where developers or other volunteers can start to create / >> change documentation immediately (in preparation for 1.8). During the >> 1.8 Release these docs can then be formally released: >> https://wiki.duraspace.org/display/DSDOCDEV/ >> So, as we do work to split up the dspace.cfg, please also try and help >> us update the Documentation in this DSDOCDEV space. >> >> - Tim >> >> ------------------------------------------------------------------------------ >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2 >> _______________________________________________ >> Dspace-devel mailing list >> Dspace-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dspace-devel >> > ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
