Enhance Activity configuration and instantiation

[fm-tibco]

I'm submitting a ... (check one with "x")

[] bug report => search github for a similar issue or PR before submitting
[x] enhancement request
[] feature request
[] support request
[] general question

Enhance Activity configuration and instantiation

The idea is to make it easier to create Activities.

• Seperate Settings from Input
• Have an instance for each configured Activity
• Allow for shared state witnin app or the construct that houses it (i.e. a flow, a stream)

Seperate Settings from Input

This will allow a clear distinction from what is configuration and what is actual "runtime" input to the Activity.

A "ActivityFactory" can be used to create activites, the factory method can take the settings for that Activity. This method would be called for each distinct configuration of an Activity. For example, it will be called for each Activity in a flow definition.

Instance for each configured Activity

The implication is that there will now be an extra instance of a struct for each configured activity in the system. But this can be offset by the fact that the settings do not need to be retained after instantiation.

Pros:

• Simpler to understand and manage
• Peformance, activities do not need to recreate everything from scratch when evaluated Cons:
• Can lead to bad behavior if each instance creates and retains handles to heavy weight objects.
  • can be mitigated, by ability to dispose/recreate tasks on the fly - for example paging out/in a definition
  • adding shared managed objects, so activites don't need to create their own copies

Metadata

Alternate way to specify metadata, possibly a go struct. Having metadata be defined in json makes using Activites difficult in a Go coding enviromnent.

[vijaynalawade]

We also need corresponding API for cleanup/destroy.