Hi Mark Diggory and Tim Donohue,

basically our intent with this development is to add some tiny features to
the configuration manager keeping it 100% backward-compatible also without
precluding the database persistence mechanism.

As i've already said, we aren't big fans of the database approach to store
configuration values (mainly because of the 3rd reason i've pointed out).

Imagine we want to change some DSpace configuration using some admin (UI)
interface. This use case will bring us (by means) to one of the topics
discussed at the previous DevMet, more properly, DSpace could be easier to
deploy (Tim Donohue said - and i agree - that the most simplistic
deployment method should be much simpler).

Our development will allow, for example, an initial configuration step for
DSpace (UI based).

PS - Is there any place to find more related discussion about the
configuration database persistence? (i wasn't able to find anything else)

On 19 July 2012 22:47, Mark Diggory <mdigg...@atmire.com> wrote:

> Lyncode,
>
> Some feedback
>
> *NOTE*: Our team have internally discussed about a database based
>> implementation (
>> https://wiki.duraspace.org/display/DSPACE/Database+Persistence+of+Configuration+State),
>> but it would have conceptual problems. Mainly:
>>
>>    - How to get the database configuration? (it must be placed somewhere
>>    - not in the database)
>>
>> Of course we thought about this.... The database is strictly to
> "override" existing configuration, thus is initially empty.  Default exist
> in separate properties files for each module within jar for that module.
> the default database configuration resides in the dspace.cfg, or more
> specifically, dspace/config/modules/database.cfg and is used to bootstrap
> the rest of the configuration tiers of the proposed Configuration Service
> during its initialization.
>
>
>>
>>    - Reading configurations from there will put an avoidable extra task
>>    on top of the DB
>>
>> Caching of configuration in the service and reloading will be sufficient
> to reduce this cost, the update mechanism already exists in the
> ConfigurationService to detect changes and refresh the configuration state.
>
>>
>>    - On database crashes, some services (that, today, do not use
>>    database at all), will also crash
>>
>> DSpace is inheritantly dependent on the database, evolution of dspace
> away from database dependency would also include migrating configuration
> away formt he database.  Thats probably a very long way off
> and extremely speculative. We can expect DSpace to need a database at its
> core to be functional for a very long time into the future.
>
>
>>
>>    - Derived values aren't advisable (it would make many SQL queries to
>>    get a simple configuration value)
>>
>> The under development SpringUI and its associated features made us
>> recognize that, changing the core ConfigurationManager, is an important
>> change to make DSpace more user friendly in the future.
>
>
> The intended target for Future configurability is the ConfigurationService
> in the ServiceManager, not ConfigurationManager, any change to
> ConfigurationManager should focus on replacing its implementation
> internally with ConfigurationService.
>
> ConfigurationService does everything that ConfigurationManager is capable
> of and additionally supports exposure of the configuration properties in
> the Spring Application Context such that they can be used in the Spring xml
> / annotation autowiring
>
> Dialogs around the Service Manager have pointed us towards
> an evolution towards a more WebMVC friendly series of refactorings.  The
> Versioning contribution will bring into place the first of these, which is
> to make WebMVC available to all webapplications within DSpace and allow an
> evolution of the XMLUI away from using Cocoon as its "Controller" and more
> strictly as just a "View" technology.
>
> Benefits:
> b.) Better loading of spring configurations for Service Manager that
> currently are a bit dirty and in the webapp
> c.) Future paths for simplifying ServiceManager and Configuration with
> focus specifically on using Spring WebMVC and any
> configuration capabilities found there.
>
> I hope you can recognize that theres been a great deal of historical
> dialog on this topic.  I highly recommend that any advances in this area be
> "collaborative" and well planned out on a roadmap.  Granted, such a roadmap
> is in its infancy at this time.  I look forward to contributing to a more
> formal roadmap with many of these ideas as it evolves.
>
> If you are working on yet another variant of the WebMVC webapplication, I
> would highly recommend not doing this internally at first, but instead
> centralize your work around some of the previous and current targets we are
> seeking to get into place for 3.0.
>
> Best Regards,
> Mark
>
>
> On Wed, Jul 18, 2012 at 12:17 PM, Tim Donohue <tdono...@duraspace.org>wrote:
>
>> Hi Lyncode,
>>
>> I'd recommend starting the discussion with a request for feedback from
>> this dspace-devel list (which you've already done in a way). This list
>> is the best place to get some immediate feedback on early ideas.
>>
>> In the case of this "Dynamic Configurations" concept, I'll admit that
>> I'm not sure I fully comprehend all your ideas (though I'm one who likes
>> to see mock-ups or examples, as it helps me better understand the
>> proposal).
>>
>> So, I'd definitely encourage you and your team to continue to document
>> your ideas & brainstorms and add more details. You should also be
>> encouraged to send ongoing brainstorms to this listserv for feedback. As
>> needed, we can always bring specific discussion topics into future
>> DSpace Developer meetings (where we have space to do so).
>>
>> Admittedly, in the coming weeks/months our Developer meeting agendas are
>> likely to get more and more busy as we work to finalize DSpace 3.0
>> features and the release in general. This means that we may have less
>> time during this one hour meeting to discuss topics which are not deemed
>> of "high priority" for the 3.0 release.
>>
>> - Tim
>>
>> On 7/17/2012 7:15 PM, DSpace @ Lyncode wrote:
>> > Tim Donohue,
>> >
>> > we would like to know what do the DSpace development team have to say
>> > about our most recent (under development) feature:
>> >
>> > https://wiki.duraspace.org/display/~lyncode/Dynamic+Configurations
>> >
>> > Mainly:
>> >
>> > - Conceptual decisions that have been taken
>> > - More features?
>> >
>> > We want to offer it to the DSpace community as a code contribution.
>> >
>> > On 17 July 2012 22:16, Tim Donohue <tdono...@duraspace.org
>> > <mailto:tdono...@duraspace.org>> wrote:
>> >
>> >     All,
>> >
>> >     Tomorrow (Weds, July 18), we will restart our weekly DSpace
>> Developers
>> >     Meetings in the #duraspace IRC channel at 20:00 UTC.  To determine
>> your
>> >     local time, check the world clock:
>> >
>> http://www.timeanddate.com/worldclock/fixedtime.html?hour=20&min=0&sec=0&p1=0
>> >
>> >     The agenda is posted on our Developer meetings page at:
>> >     https://wiki.duraspace.org/display/DSPACE/Developer+Meetings
>> >
>> >     The notes from last week's meeting are also available off of the
>> >     "Meeting Archives" area of that page.
>> >
>> >     As always, all our meetings are public.  We welcome any developers
>> or
>> >     non-developers to attend or just read along with the chat
>> discussions.
>> >
>> >     If you are unable to attend, you can always add your own
>> notes/thoughts
>> >     on any agenda item to the above wiki page.
>> >
>> >     == DSpace Office Hours ==
>> >
>> >     I will be holding my weekly Office Hours tomorrow from 17:00-20:00
>> UTC
>> >     (just before the Developers Meeting). Any developers are welcome to
>> stop
>> >     in to chat about any DSpace related topics or issues. More
>> information
>> >     on the wiki page below:
>> >
>> >     https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours
>> >
>> >     Thanks,
>> >
>> >     Tim Donohue
>> >     Technical Lead for DSpace Project
>> >     DuraSpace.org
>> >
>> >
>> ------------------------------------------------------------------------------
>> >     Live Security Virtual Conference
>> >     Exclusive live event will cover all the ways today's security and
>> >     threat landscape has changed and how IT managers can respond.
>> >     Discussions
>> >     will include endpoint security, mobile security and the latest in
>> >     malware
>> >     threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> >     _______________________________________________
>> >     Dspace-devel mailing list
>> >     Dspace-devel@lists.sourceforge.net
>> >     <mailto:Dspace-devel@lists.sourceforge.net>
>> >     https://lists.sourceforge.net/lists/listinfo/dspace-devel
>> >
>> >
>> >
>> >
>> > --
>> > Thanks, DSpace @ Lyncode
>> > DSpace Department
>> > *Lyncode*: Official website <http://www.lyncode.com/>
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Dspace-devel mailing list
>> Dspace-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>>
>
>
>
> --
> [image: @mire Inc.]
> *Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
> *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
> *Esperantolaan 4, Heverlee 3001, Belgium*
> http://www.atmire.com
>
>
>


-- 

Thanks, DSpace @ Lyncode
DSpace Department
*Lyncode*: Official website <http://www.lyncode.com/>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to