ESciDoc Developer Workshop 2008-09-30

ESciDoc

Date: 30.09.2008 Start time: 15:30

Location: Karlsruhe, München (Video conference)

Participants MPDL: Natasa Bulatovic, Wilhelm Frank, Thomas Endres

Participants FIZ: Michael Hoppe, Matthias Razum

=Agenda=

Last Video conference outcome

 * available at ESciDoc Developer Workshop 2008-09-23

Bug Fixes & Patch for pre-release 1.0
Is it possible to have bug-fix for 1.0.beta4. build 306 (stable release)?


 * 659 Revoke grants - filters (3.0.6) (important, authorization issue) => resolved in build 307
 * 662 Search with special characters is not working properly (very important) => resolved
 * Outcome:not in 311 -> Matthias will check with Andre if changes to the filtered cache list are already included -> MPDL will have a HowTo list for migrating the Db
 * 655 prop:valid-status for components required => not certain on status
 * Outcome: Michael (MPDL) will check on the status of this issue


 * Otherwise, already mentioned blocker:
 * 637 Content download (blocker) => see also 1.0 prio
 * Outcome:Steffen works on this heavily, not certain when we will have a fix on this topic

Outcome

 * Overall dicsussion: current developer builds should be usable only by switching the ear file (there are no interface or schema changes). Exceptions are filters: MPDL can accept the existence of 1 distinct filter per filter request and 1 sorting criteria. Matthias will check with Andre if in addition we need to make some database changes in the local installation - to be able to start testing the filters. If so, then MPDL will receive a script that does it.
 * The already delivered migration utility from build.297 (beta3) to build.304 (beta4) does not include the latest database changes!
 * If in a meantime there is a schema change FIZ will inform

Discussion on release 1.0

 * priorities agreement (related info: email from Matthias, Malte-Matthias phone call)
 * Release 1.0 will not come end of September, postponed 3-4 weeks
 * Release 1.0 should resolve the following
 * 1. content download (issue 637) - non thread safe code
 * Outcome:Show stoper, no release 1.0 without a fix for this bug
 * 2. Filter solution (needs pre-testing on developer version) (schema change possible)
 * Outcome: Implemented, it needs some more testing on our side, Matthias will check on Db schema change and what that means, see Outcome for bug-fix of pre-release 1.0
 * 3. Institutional Visibility (Natasa, Michael exchanged more details, see discussion below) (schema change possible)
 * Outcome:to be checked if it has impact on the XSD schemata - as visibility property will stay but the values can be changed.
 * todo: remove element value "institutional" and add element value for "audience"
 * question is whether to create new version schema or simply use the same schema?
 * question is also whether to keep the value of "private" or replace it with the value of "internal"
 * FIZ will think on this issue (especially on schema version change). Both teams agree that clear description of what "private" or "internal" means is needed in any case.
 * If schema is changed and "private" replaced with "internal" migration procedure should consider this
 * 4. ingest interface and a *very* simplistic ingest client (needs pre-testing on developer version)
 * 5. the ingest bug (non thread-safe code issue 636) non thread-safe code (related to previous)


 * FIZ proposal to test filters and ingest interface on developer version
 * MPDL will not be able to test before the content download is resolved
 * MPDL proposal is to focus on following priorities (ordered by relevance for MPDL):
 * 1. content download (Blocker for MPDL solutions) and ingest bug
 * 2. Filter solutions
 * FIZ suggest that we start testing... related above
 * 3. Institutional visibility
 * 4. Ingest interface
 * MPDL can not do any testing before the blocker is resolved (bug-fix on pre-release 1.0 is essential)
 * In meantime on pre-release 1.0 MPDL will only be able to test the migration from build.297 to pre-release 1.0

Outcome

 * As FIZ heavily works on resolving the multi-threading issue it makes no sense that MPDL does not test the filters at least.
 * MPDL can test the filters if provided with script/procedure to migrate to evtl. changed db structure for filters
 * Institutional visibility and ingest -> will not be tested until fix and new functionality is provided, most probably not before release 1.0 is delivered
 * see also outcomes on particular bullet points

eSciDoc access rights and institutional visibility

 * first functional sketch for retrieval (read access only, not yet dealing with updates) of components is on eSciDoc Access Rights
 * Michael&Natasa agreed on approach, Michael sent a concept paper
 * discussion on the concept and further implementation

Outcome

 * The concept is clear to all
 * beside the "audience" visibility on component level we need actually definition of 2 new role: Audience and Colaborator
 * the roles of Audience and Collaborator can be associated to a user or a user group for a particular scope.
 * the Audience role is clear and can be defined for the scope of the component
 * the Collaborator role can be defined for the scope of the component, item, container, context


 * Mostly talking on optimization and fast association of the user with a user group, as being the eSciDoc core services are stateless, each user request must undergo the same procedure
 * MPDL proposal: maybe the current handle management can be used to set-up these as extra attributes for each assigned handle (as it is anyway a simple way of session management)


 * Teams agreed on starting with 3 different ways of specifying a user group:
 * a user group can be specified for list of users
 * a user group can be specified for list of organizational units (all users of specified OUs and OU children will automatically be part of the group)
 * a user group can be specified for list of other user groups


 * When user group is specified for list of organizational units: the solution should be responsible to relate user-proxies with a particular OU id - users will not automatically be part of the user group based on OU even if they come from the right institution.


 * Teams agreed that we need to specify User group handler. Michael (FIZ) will put the initial Colab page on this.
 * both teams agreed that for start the only attribute based on which a user coming via Shibboleth can be identified and evtl. associated with the group is the username of the user. The user handler core service should be used to set-up the OU of this user, to enable OU based group association.
 * both teams agreed that the need to specify some more attributes that allow user to be associated with the group can be considered in future


 * IP-based access: not really clear how users would be able to be authenticated via their IP and associated with the user-proxy in the escidoc (without need to explicitly log-in) - this will be additionally checked when we have more clear understanding

Miscelaneous

 * Build process and version numbers for stable-releases, development builds and bug-fix patches of stable-releases
 * Admin tool works for re-indexing OUs?
 * Very nice: each change in OU is immediately visible in the Lucene index, OU searching works fine so far

Outcome

 * FIZ will change complete Build process. ( eSciDoc ESciDoc Core Publishing)
 * Timing: Build process will be changed after the multi-thread bug is solved
 * FIZ will inform MPDL on the concept and meaning of build numbers
 * Until new build process is adopted:
 * FIZ will inform MPDL whenever there are interface changes in place (as at the moment each dev-build is a bug-fix, and there is no separate branch for stable release bug-fixes)
 * FIZ will also inform MPDL whenever there is migration necessary (or there is change in database structure, Fedora XMLs, etc.) -> and will provide migration procedure


 * Admin tool works for reindexing of OUs
 * Update MPDL: tested after the VidCo - works

Next eSciDoc Workshop

 * München, 14-15.10.2008
 * Agenda at ESciDoc München Workshop 14-15.10.2008