search

niaid / image_portal_workflows

Workflows related to project previously referred to as "Hedwig"
BSD 3-Clause "New" or "Revised" License
5 stars 1 forks source link

Consider adding more "secret" params to WF API #380

Open philipmac opened 11 months ago

philipmac commented 11 months ago

It may be useful to allow extra functionality / arguments / control to be injected into the WFs to help debugging, tune per run optimizations, etc.

For example: log level: bool, bioformats chunk size: int, ng_shader_param_quantiles: [float, float] rechunk_in_memory: bool

blowekamp commented 11 months ago

Note common logging systems use "[DEBUG|INFO|WARNING|ERROR]" for logging levels.

annshress commented 11 months ago

Maybe, we can load them from .env file. Currently we have them already setup.

Passing these variables into functions during the testing phase to be able to test and tune parameters sounds good.

philipmac commented 10 months ago

We could make current "secret" params clearer.

philipmac commented 10 months ago

prefix any param that is not for public use is prefixed with x_

note - if the param is exposed at some later point, the x_ can be removed, the param can remain unchanged and now be "public"

annshress commented 10 months ago

This is inspired by HTTP experimental or non-standard/custom headers.

In HTTP headers, the "X-" prefix is often used to denote non-standard or custom headers. Standard HTTP headers are defined by specifications like those outlined in the HTTP/1.1 RFCs (Request for Comments). However, developers and organizations may introduce custom headers for specific purposes. The "X-" prefix indicates that a particular header is an extension or experimental header that is not part of the official HTTP specification. This naming convention helps prevent clashes with future standard headers that might be introduced in subsequent HTTP versions.