Convention for metadata written by tasks

[martinklepsch]

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.

[podviaznikov]

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

[martinklepsch]

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.

[podviaznikov]

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.

[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?

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.

[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?

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.

[martinklepsch]

@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]

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

[Deraen]

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

[MartyGentillon]

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.

[allentiak]

Hi, @Deraen @martinklepsch @podviaznikov @MartyGentillon ,

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