DCValue -> MDValue

[joao-de-melo]

Hi Richard,

how hard it would be to change the current dspace-api (DSpace 3.0) to adopt MDValue instead of DCValue?

[richardrodgers]

Hi João:

I'd say there are 2 different answers to that question:

(1) In narrow code refactoring terms, it's not that hard: mostly just changes in the signatures and a bit of the internals in the classes that produce or consume DCValue objects (that's mostly Item.java) In mds, I made a few other changes (see:https://github.com/richardrodgers/mds/wiki/Refactor-Candidates section on MDValue for details).

(2) However, in the broader sense, it would not be trivial, because it does break the core DSpace content API, which is published and stable. Since this API is used by:

A. so-called 'business logic' layer of DSpace,
B.UI and other code of all kinds,
C. local customizations of all sorts that we cannot see!

This leads to difficult choices, which include:

(1) Retain the original DCValue methods, add @deprecated annotations to them, and add the MDValue methods along-side them as recommended replacements.
This approach would entail either duplicating the logic in both implementations, or (probably better, but a bit messy) rewrite DCValue methods to call MDValue replacements under the hood. It also delays 'judgement day' to some future release when the deprecated stuff would be removed. But it would allow new code to use the preferred idiom.

(2) Replace DCValue with MDValue in the API. Rewrite all calling code in categories A. and B. above. I have not surveyed how extensive this work would be, but there might be tricky cases to consider. For example, do we change all UI code or only XMLUI? How about modules like LNI that are not widely used? In this scenario we would have to do a lot of community outreach to encourage customizers in category C. to refactor before upgrading (on pain of their systems not compiling). There would also be an avalanche of regression testing, since a lot of code would change (even if trivially).

And I could continue with other variants, but I think you see the picture I'm trying to paint.

I was fortunate in mds in deliberately not worrying about backward code compatibility - the changes are so extensive that it is not feasible. In mds, I can provide 'data-portability',
not 'code-portability' (i.e. writing conversion scripts to turn a DSpace repo into an mds repo).

Does this answer your question? If not. please let me know.

Regards,

Richard

On Dec 20, 2012, at 1:28 AM, João Melo wrote:

Hi Richard,

how hard it would be to change the dspace-api to adopt MDValue instead of DCValue?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1.

[joao-de-melo]

Yes, it answers my question, thanks.

At the last dev mtg (http://irclogs.duraspace.org/index.php?date=2012-12-19) some dspace committers stated that it would be interesting to improve the current dspace-api, even if those chages cause some core breaks, however it must be modified soon as possible (so there is time to make all required changes). So i guess it could be a good oportunity to remove this deprecated code.

We are working on a core change (DAO approach). I would like to invite you to help us applying this very specific change (MDValue) to the current DSpace API (https://github.com/lyncode/DSpace/tree/core-changes).

We are expecting to come with a DAO proposal in the following weeks.
I think it would be nice to add this change too.

And well, that's it.

PS - If we don't talk earlier, merry christmas.