RFC: eventbus message format

[Ingvord]

As first JSON approximation:

{
  "meta":{
    "target":"string - upstream system e.g. tango or epics",
    "source":"string - downstream system e.g. web, tango",
    "action":"string - defines action required e.g. for tango - read/write attribute etc",
    "user":"string - username"
  },
  "payload":"data",
}

For HTTP we can use headers with some prefix e.g. Z-target to specify meta info and BODY for (binary) payload

[altavir]

Some questions/requests based on our experience in DataForge:

• Does source/target contain name of specific device or only system name? If it is system name, how to know, which device it belongs to?
• user must be a node for login information etc.
• How does name <-> widget mapping?
• How does name <-> device mapping work in case of multiple back systems?

[Ingvord]

• Does source/target contain name of specific device or only system name? If it is system name, how to know, which device it belongs to?

Agree. This needs to be clarified. For Tango I would say it is OK to provide full name here e.g. tango://host:port/domain/family/member/[attribute/command/pipe/property]. I am not sure about other systems - whether it will be always convenient to specify the full URL

Maybe it is better to make target a node with all the values separate

OR

to provide a dedicated node with exact address for each upstream system e.g.

{
  "upstream":"tango",
  "target":{
    "host":"host:port",
    "device":"domain/family/member",
    "attribute":"my_attr"
  }
}

• user must be a node for login information etc

Well, if upstream system supports login... sure. Tango per se does not, so username is enough. It is better to protect server-side entry point of the eventbus with standard mechanism i.e. Basic or OAuth anyway.

How does name <-> widget mapping

There is no such mapping. In the client Eventbus is not widget agnostic it sole role is to publish incoming messages and push outcoming. It is widget's responsibility to subscribe to a particular messages channel

How does name <-> device mapping work in case of multiple back systems?

I would say 1 <-> 1, for instance in Tango, if we update several attributes we push several messages in an array

[altavir]

I think that string format should be arbitrary because different system could have different formats. In DataForge we use composite naming scheme like a.b.c where b is part of a. The address is not encoded in the name, it is done by separate mapper. We need to study different use cases, but if we consider only tango and DF, then it make sense to crate separate fields inside target node:

• scheme (tango, DF, EPICS, etc). May default to tango
• host (optional for DF, but required for TANGO)
• name (device name in appropriate scheme)

Optionally, we can add a tag array to mark specific messages independently from its origin or destination.

Attribute name should be a separate parameter since it belongs to action, not device.

If we have several severs-side systems, we must have a mapper that redirects requests with different schemes or different domain names to different servers, but it is an implementation detail.

[Ingvord]

See RFC-1

[Ingvord]

I assume this can be closed by now as we already have RFC-1. Further changes should be done through standard workflow