perun icon indicating copy to clipboard operation
perun copied to clipboard

Convention for metadata written by tasks

Open martinklepsch opened this issue 10 years ago • 10 comments

Probably a good idea to establish some sort of namespacing for metadata i.e. perun/markdown can only write to :perun/markdown key in metadata.

martinklepsch avatar Jun 18 '15 21:06 martinklepsch

Can you describe with more details why that might be useful?

podviaznikov avatar Jun 19 '15 03:06 podviaznikov

I was just thinking that if perun encourages people to extend it with other tasks there probably should be some convention about how/where they store task related data.

Given we change the :metadata key to :io.perun or something similar as discussed in #22 the structure could end up looking like this

{:io.perun {:markdown/html "<h1>Title</h1>"
            :ttr "2min"}}

i.e. there is some loose mapping from task name to the keys the tasks write to. Currently the markdown task writes to :content which is very generic and could be easily overwritten by other tasks in the pipeline.

martinklepsch avatar Jun 19 '15 08:06 martinklepsch

Not 100% sure about this. In such case tasks further in the chain need to know name of props like markdown/html. This seems to introduce explicit coupling between tasks. E.x. now renderer task function should be aware of markdown/html. My initial idea was to have some default props for each task (like content, ttr) but name of that property can be changed using task options.

podviaznikov avatar Jun 19 '15 17:06 podviaznikov

E.x. now renderer task function should be aware of markdown/html.

I see your general point but doesn't the renderer function now equally need to be aware of :content?

My initial idea was to have some default props for each task (like content, ttr) but name of that property can be changed using task options.

Making them customizable is probably a good idea in any case.

martinklepsch avatar Jun 19 '15 17:06 martinklepsch

E.x. now renderer task function should be aware of markdown/html.

I see your general point but doesn't the renderer function now equally need to be aware of :content?

I'm thinking that if you replace markdown with some other task/plugin render function would still work if it uses :content. Basically I see :content is like interface and :markdown/html as implementation detail.

Another idea: we can have some global option that turns namespacing on/off. This way we might have both solutions.

podviaznikov avatar Jun 19 '15 18:06 podviaznikov

@podviaznikov I'll think about this a bit more but one thing to keep in mind is that the render task does not directly use :content, only the function supplied as renderer does. And this function is user supplied.

martinklepsch avatar Jun 19 '15 18:06 martinklepsch

@Deraen do you have thoughts on establishing some sort of convention for tasks and the keys in metadata they're writing to?

martinklepsch avatar Jun 20 '15 22:06 martinklepsch

Not really. But I would avoid anything which prevents using :keys destructuring, like namespace qualified keywords.

Deraen avatar Jun 21 '15 07:06 Deraen

The real problem with this is that it would mean that you could never use the same renderer for something in markdown and something in some other format. Overall, format is an implementation detail, and a website could have both markdown files and HTML fragments. Both of these may want to use the same templating.

MartyGentillon avatar Sep 30 '16 02:09 MartyGentillon

Hi, @Deraen @martinklepsch @podviaznikov @MartyGentillon ,

There hasn't been any activity on this thread for over three years... Should we close it?

allentiak avatar Jan 31 '20 20:01 allentiak