Metadata support: Extensions handling

Brent Putman putmanb at georgetown.edu
Mon Aug 12 20:50:02 EDT 2013


On 8/12/13 8:37 PM, Cantor, Scott wrote:
>
> I had envisioned a whitelist of extensions to process naively (meaning the
> XML be copied) and then others that would be handled in more precise ways,
> and then stuff that just would be ignored.

Conceptually that's more or less what I was thinking, but the nature of
extensions being what it is (extensible, not known in advance, etc), I
gravitate more to the plugin-oriented approach, rather than baking in
support for some things in the providers.

>
> Yes, so I mainly meant not assuming that simple approaches wouldn't work
> fast enough until they're proven not to. And there's always the
> expectation that it really can't scale in batch form in the end anyway, so
> how much work do you do to make it better?

All true. With metadata batches in particular, we do have some
historical experience and reason to believe that those have substantial
time and/or memory costs.  So I'm just trying to be cautious.  You're
right that we don't want to prematurely over-optimize.  Changing
approaches in the middle however will mean re-writing the guts of the
providers, so hopefully we'll get it right on the first go.

I'd like to think that (large) batches are going to go away soon, but I
fear that they will not, at least in the timeframe of v3 (v4...?)


More information about the dev mailing list