Syndrome/Protocol generic template (with substitutable parameters)

XMLWordPrintable

    • Type: Task
    • Resolution: No Action
    • Priority: Major
    • None
    • Hide

      1. First, I provide a use case where this template idea is required:
      Detect symptom A & B where A.hostname=B.hostname and A.instancename='Blah'. Fyi - A might be an application?
      It would be great to allow "Blah" to be populated by the syndrome implementer.
      So, the syndrome might be published into the catalog by a Cloud provider as follows:
      Detect symptom A & B where A.hostname=B.hostname and A.instancename=?.

      2. Next, how would we support this notion in the spec:
      We would need some wildcard character (such as the ?) to designate to the authoring tools that this value should be substituted.

      Show
      1. First, I provide a use case where this template idea is required: Detect symptom A & B where A.hostname=B.hostname and A.instancename='Blah'. Fyi - A might be an application? It would be great to allow "Blah" to be populated by the syndrome implementer. So, the syndrome might be published into the catalog by a Cloud provider as follows: Detect symptom A & B where A.hostname=B.hostname and A.instancename=?. 2. Next, how would we support this notion in the spec: We would need some wildcard character (such as the ?) to designate to the authoring tools that this value should be substituted.

      Syndromes signature & Protocol directives could be generic in nature, containing substitutable parameters.
      For example, signature could be (in English, not xpath/xquery): if blah occurs

      {0}

      times within

      {1}

      minutes.
      The Syndrome/Protocol would be effectively instantiated by substituting meaningful values, such as "if blah occurs 3 times within 5 minutes.
      This is critical from the collaboration perspective, ie: Cloud provider could publish generic Syndromes, while consumers could instantiate those Syndromes per above.
      Notes
      Might require no changes to the spec. Interfaces might better support this?

            Assignee:
            Jeffrey Vaught (Inactive)
            Reporter:
            Jeffrey Vaught (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: