Add NecrOPTIMADE provider

[ml-evs]

This PR adds a provider for the WIP NecrOPTIMADE service, currently hosted on Heroku.

The index meta-database is dynamic and currently only contains a single implementation if it has been requested at the extensions/spawn endpoint since the last deployment. Some more notes can be found at ml-evs/necroptimade.

[merkys]

The index meta-database is dynamic and currently only contains a single implementation if it has been requested at the extensions/spawn endpoint since the last deployment. Some more notes can be found at ml-evs/necroptimade.

From the analogues in the specification I gather that all nonstandard names have to be prefixed with database-specific prefix. As there are no standard extensions in v1.0.0, I think all of them have to be prefixed, thus it should be extensions/_necro_spawn. But I may be wrong. Specification is rather implicit on this matter.

[rartino]

From the analogues in the specification I gather that all nonstandard names have to be prefixed with database-specific prefix. As there are no standard extensions in v1.0.0, I think all of them have to be prefixed, thus it should be extensions/_necro_spawn. But I may be wrong. Specification is rather implicit on this matter.

This is not how I remember the intent with /extensions, but rather that it was to be completely under the API implementation's control. The specification says "The API implementation is free to define roles of further URL path segments under this URL." I think the "any URL goes" is a reasonable interpretation in the absence of any clarification that only prefixed path segements are acceptable.

As for the prefix, the 'necro' naming is fun and all; I'll of course approve it if that is want you want. But, wouldn't something like 'archive' be more... informative.... for this service?

[merkys]

From the analogues in the specification I gather that all nonstandard names have to be prefixed with database-specific prefix. As there are no standard extensions in v1.0.0, I think all of them have to be prefixed, thus it should be extensions/_necro_spawn. But I may be wrong. Specification is rather implicit on this matter.

This is not how I remember the intent with /extensions, but rather that it was to be completely under the API implementation's control. The specification says "The API implementation is free to define roles of further URL path segments under this URL." I think the "any URL goes" is a reasonable interpretation in the absence of any clarification that only prefixed path segements are acceptable.

I stand corrected. Indeed, the implementation is free to use any URL after /extensions.

[rartino]

Approved

(But consider if "necro" is the best prefix. To clarify my point I see no issue with calling the software that serves archived databases necrOPTIMADE, but the greek prefix for "death" may now end up staying with us for a long time to refer to the OPTIMADE-associated standard archival service...)

[ml-evs]

As for the prefix, the 'necro' naming is fun and all; I'll of course approve it if that is want you want. But, wouldn't something like 'archive' be more... informative.... for this service?

I get what you are saying, but I don't think I want this to look like an official archive and see this as more of a capability test. If it goes well, I would be more than happy to move to a central optimade.org hosting with a less jocular name...

(But consider if "necro" is the best prefix. To clarify my point I see no issue with calling the software that serves archived databases necrOPTIMADE, but the greek prefix for "death" may now end up staying with us for a long time to refer to the OPTIMADE-associated standard archival service...)

I'm willing to think about this for a bit, as you say the prefix/id is more permanent than the name itself, so maybe just nec is more appropriate?

[ml-evs]

It's actually an open question how this service should use prefixes. If two static db's want to host the same custom field with different meanings, then _necro_cell_volume (for a primitive cell) and _necro_cell_volume (for a simulation cell) would be problematic (even if the corresponding info endpoints had the correct description). A local prefix for a particular implementation would make sense (though it could be hard to generate a name), but of course these would not be registered here...

[rartino]

I get what you are saying, but I don't think I want this to look like an official archive and see this as more of a capability test. If it goes well, I would be more than happy to move to a central optimade.org hosting with a less jocular name...

Sure, if one sees this as preliminary testing, then any prefix is fine. However, I suspect this is going to be OPTIMADE-adopted, and the prefix will stick with us because there likely will be some breakage in changing it at that point.

Well, feel free to make the decision you prefer if no one else chimes in; we've already reached the necessary approvals.

(I'm not sure if 'nec' vs 'necro' makes much difference; perhaps it sticks out a little bit less :-) )

[ml-evs]

Sure, if one sees this as preliminary testing, then any prefix is fine. However, I suspect this is going to be OPTIMADE-adopted, and the prefix will stick with us because there likely will be some breakage in changing it at that point.

I don't see this is as a problem, I think a proper OPTIMADE archive would just be a separate provider.

I will merge this as it is, and we can see how it goes. Perhaps we need a mechanism to eventually deprecate providers in this list, so we can use this as a test case...