ETSI's Bug Tracker - Ext Pack: Config & Deployment Support (ES 202 781)
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007768 | Ext Pack: Config & Deployment Support (ES 202 781) | New Feature | public | 25-05-2018 12:01 | 05-01-2019 11:01

Reporter | KristÃ³f Szabados |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version |  | Fixed in Version | v1.7.1 (published 2019-04) |
Clause Reference(s) | 5.2.4
Source (company - Author) | L.M. Ericsson
TS version | n/a

Summary | 0007768: add support for stateful translation ports

Description

Section 5.2.4 in the Configuration and deployment extension pack describes how one can create ports with translation capability.
In the text and syntactical structure this section shows that ports can have variables, that can be accessed from translation functions referencing that port.
The example on page 21 also shows that the port of translation functions (with a port identifier) is accessible from within the translation function using the "port" keyword.
From this it would naturally follow, and be very usefull if users could declare statefull ports, to simplify their tests.
For example when someone just wants to send single message and check the response to it in the current core standard he/she has to write the entire protocol handling in TTCN-3 just to get to the point of sending the message.
With statefull behaviour allowed inside translation ports the translation function itself could take the responsibility (by implementing a statemachine) ... signifficantly reducing the complexity on the user's side.
For a detailed example with MQTT please look at: https://www.eclipse.org/forums/index.php/t/1092981/ [^]
---
Please note that, the current wording does not seem to restrict the above behaviour.
So we might just need to add more detailed examples and text, that actually show : how port variables can be accessed from the translation function, and send/receive operations called on the "port" in translation functions.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR_7768.docx (145,240) 20-07-2018 08:31 http://oldforge.etsi.org/mantis/file_download.php?file_id=3780&type=bug CR_7768-v2.docx (181,275) 11-10-2018 09:42 http://oldforge.etsi.org/mantis/file_download.php?file_id=3798&type=bug

Issue History
Date Modified | Username | Field | Change
25-05-2018 12:01 | KristÃ³f Szabados | New Issue |
16-07-2018 14:21 | Jens Grabowski | Assigned To | => KristÃ³f Szabados
16-07-2018 14:21 | Jens Grabowski | Status | new => assigned
16-07-2018 14:21 | Jens Grabowski | Note Added: 0015133 |
20-07-2018 08:31 | KristÃ³f Szabados | File Added: CR_7768.docx |
20-07-2018 08:32 | KristÃ³f Szabados | Note Added: 0015182 |
20-07-2018 08:32 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Tomas Urban
20-07-2018 08:32 | KristÃ³f Szabados | Status | assigned => confirmed
20-07-2018 09:30 | Jens Grabowski | Status | confirmed => assigned
20-07-2018 12:59 | Jacob Wieland - Spirent | Note Added: 0015190 |
11-10-2018 09:42 | Tomas Urban | File Added: CR_7768-v2.docx |
11-10-2018 09:42 | Tomas Urban | Note Added: 0015247 |
11-10-2018 09:42 | Tomas Urban | Assigned To | Tomas Urban => Kristof.Szabados
11-10-2018 09:42 | Tomas Urban | Status | assigned => confirmed
11-10-2018 11:20 | KristÃ³f Szabados | Assigned To | Kristof.Szabados => KristÃ³f Szabados
11-10-2018 11:20 | KristÃ³f Szabados | Status | confirmed => assigned
11-10-2018 11:21 | KristÃ³f Szabados | Status | assigned => confirmed
12-10-2018 08:25 | KristÃ³f Szabados | Note Added: 0015267 |
12-10-2018 08:25 | KristÃ³f Szabados | Status | confirmed => resolved
12-10-2018 08:25 | KristÃ³f Szabados | Resolution | open => fixed
12-10-2018 08:25 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Jens Grabowski
05-01-2019 10:56 | Gyorgy Rethy | Note Added: 0015315 |
05-01-2019 10:56 | Gyorgy Rethy | Status | resolved => closed
05-01-2019 10:56 | Gyorgy Rethy | Fixed in Version | => v1.7.1 (published 2019-04)
05-01-2019 11:00 | Gyorgy Rethy | Assigned To | Jens Grabowski => Gyorgy Rethy
05-01-2019 11:00 | Gyorgy Rethy | Status | closed => assigned
05-01-2019 11:01 | Gyorgy Rethy | Status | assigned => closed

Notes

(0015133)
Jens Grabowski
16-07-2018 14:21

STF discussion: Kristof to develop a proposal.

(0015182)
KristÃ³f Szabados
20-07-2018 08:32

Please check.

(0015190)
Jacob Wieland - Spirent
20-07-2018 12:59

in the STF discussion about this, we came to the opinion that one way to solve this issue is to declare some component types as 'bridge' or 'translation' components which can execute full-fledged behavior without any additional restrictions.
These translation components should mark pairs of in/out ports as some sort of 'connection' so that whenever a translated message that is received from the in-port of a connection is sent over the out-port of a connection, this is traceable at runtime so that the ingoing connection/mapping and the outgoing connection/mapping can be connected to a single 'arrow' from first source to last destination. Tools can then filter out displaying of such translation ports and treat messages to and from like direct messages between the other ends of the connections.

(0015247)
Tomas Urban
11-10-2018 09:42

Resolution proposal uploaded, please check.

(0015267)
KristÃ³f Szabados
12-10-2018 08:25

looks fine to me.

(0015315)
Gyorgy Rethy
05-01-2019 10:56

Added to v4.6.2