Timestamps are in GMT/BST.
[6:41] -verne.freenode.net- *** Looking up your hostname...
[6:41] -verne.freenode.net- *** Checking Ident
[6:41] -verne.freenode.net- *** Found your hostname
[6:41] -verne.freenode.net- *** No Ident response
[6:42] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:42] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:42] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[9:00] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (Read error: Connection reset by peer)
[9:00] * DSpaceSlackBot1 (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[9:56] <DSpaceSlackBot1> <sven> Regarding item-submission and submission-definition, and input-forms as well. Will it be possible to have a better mapping than the current <submission-map> and <form-map> ? Especially will inheritance be implemented ? "chicken and the egg dilemma" :slightly_smiling_face: which was first. I am thinking about a runtime configuration when a collection is added it inherits the submission and form definitions. Or
[9:56] <DSpaceSlackBot1> metadata for a collection in which the submission-definition and form-map is linked.
[10:09] <DSpaceSlackBot1> <sulfrian> Yes, I also would prefer to manage the submission-definition as part of the collection metadata. Especially when sharing the submission-definition between multiple (test) systems with a different collection/community structure it would be a lot of easier, if the mapping would be attached to the collection.
[10:25] <DSpaceSlackBot1> <sven> @sulfrian Ofc multiple test systems with different structures is a big point. If there can be a handy solution in dspace7 could be a huge win.
[12:09] * mhwood (~email@example.com) has joined #duraspace
[13:10] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[13:21] <DSpaceSlackBot1> <tdonohue> RE: the DSpace 7 submission config changes...they are discussed in more detail on this wiki page: https://wiki.duraspace.org/display/DSPACE/Configuration+changes+in+the+submission+process To clarify, in DSpace 7 we are *not* attempting to recreate / redesign submission configuration (as that's a massive endeavor itself). We are simply _tweaking_ the existing configuration files to allow them to work better
[13:21] <DSpaceSlackBot1> more easily managed via a REST API and interact with an Angular UI). Any larger scale configuration changes would have to wait until post-DSpace 7. We simply cannot change/fix everything in a single release ;)
[13:26] * helix84 (~ctenar@unaffiliated/helix84) Quit (Remote host closed the connection)
[13:43] <DSpaceSlackBot1> <sven> @tdonohue I understand the problem of too many changes at once. I asked myself just a question if endpoints are written which result they probably can return. Returning inherited submission-definition , for my idea, could be worth implemented here and shall be possible to implement
[13:43] * helix84 (~ctenar@unaffiliated/helix84) has joined #duraspace
[13:57] <DSpaceSlackBot1> <tdonohue> @sven: this work is all still "in progress" on DSpace 7. So, feedback is welcome. As noted, the latest info on the configuration redesign is at: https://wiki.duraspace.org/display/DSPACE/Configuration+changes+in+the+submission+process And, if you'd like to see the latest design for the REST endpoints, take a look at the `/api/config/submission*` endpoints described in the REST contract:
[13:57] <DSpaceSlackBot1> https://github.com/DSpace/Rest7Contract/blob/master/endpoints.md
[13:58] <DSpaceSlackBot1> <tdonohue> This all is very much a work in progress though, and it could change as the code development progresses. But, that's the latest ideas so far, and we do welcome feedback
[19:26] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Read error: Connection reset by peer)
[21:01] * mhwood (~firstname.lastname@example.org) Quit (Remote host closed the connection)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.