On Fri, Jan 18, 2013 at 6:11 PM, Christian Völker <C.Voelker@...> wrote:
> Am 18.01.2013 um 13:03 schrieb helix84 <helix84@...>:
>> That's right, the setter/lifter is custom code. I always assumed the
>> DefaultEmbargoSetter/DefaultEmbargoLifter classes are something like a
>> placeholder, meant to be customized, because they are very limiting.
> A placeholder meant to be refined an piece of code meant to replace
> the placeholder sounds like time for providing a patch, isnt it?
> And it would remove the need for clarification about current
> limitations, less documentation to read, to write and to be kept
> up to date. Would be great if you could get your custom methods
> into the mainstream code I guess. I say thank you in advance.
Actually, while I have no problem with sharing the code, the point why
I don't is that it is very specific to my needs (e.g. my definition of
the meaning of a primary bitstream and other details I didn't
mention). It's really not suitable for upstreaming, certainly not as
the default. In fact, that was the intention of the 1.6 embargo - to
let you define the policy yourself. It may be unfortunate that the
policy is expressed as Java code, which raises the barrier to entry.
That's also the reason why the common use case was refined and given
UI elements in the 3.0 embargo. So back to my original point - what
Bram mentioned might be the default, but it certainly wasn't fixed,
even if hard to customize by non-programmers. The option to define
custom policy is still available in 3.0, 3.0 just makes the common use
As we speak, I'm working on something that might lower the barrier a
bit, but it's still in the experimental stages.
Compulsory reading: DSpace Mailing List Etiquette