[Weekly Meeting] [2024-02-08] - Meeting Notes

[ricardozanini]

Proposed topics:

• Event data should accepts json object with expressions not just a single expression as string.  #815
• EventTimeout supporting expression #816
• Refactoring the current rest operation to simple "HTTP" since this new operation is essentially a shortcut for the openapi one. Maybe merging those two and introducing a simplistic approach for making "curls"?

@fjtirado is willing to take some tasks from our backlog.

[ricardozanini]

• - @ricardozanini to cleanup the Java SDK main branch and align with the 0.8 branch based on the latest release
• - @ricardozanini to incorporate rest and openapi functions
• - @fjtirado to assess workflow.id and workflow.key is duplicate #742

[ricardozanini]

Regarding #742:

• Keep key as an optional string expression and rename it to something that resembles a domain template expression to be composed in runtime.
• Use name as the required, unique workflow identification
• Remove id from the spec.
• version can be optional, runtimes can set to latest by default.

@cdavernas @JBBianchi @fjtirado cc

[ricardozanini]

@cdavernas to name the new key attribute

[ElanHasson]

So id is being changed to key is the take away here?

In my read-through of the spec, I interpreted ID to be something like a uuid or whatever specific to the implementation system to uniquely identify that thing and name as a friendly human readable thing.

Is that the intention of key?

[cdavernas]

The key attribute is a runtime expression used to generate a domain-friendly identifier for instances of the workflow definition.

id was used for the purpose you describe, which should be implem specific and therefore stripped out of the spec. As per spec, workflows should be referenced by their DNS friendly name (and version, if any, or 'latest').

[ElanHasson]

makes sense.. metadata it is!