ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007738 | Part 06: TTCN-3 Control Interface | New Feature | public | 19-12-2017 15:43 | 16-01-2019 12:42

Reporter | Jacob Wieland - Spirent |
Assigned To | Tomas Urban |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.9.1(ongoing) |
Target Version | Next version (to be defined) | Fixed in Version | Next version (to be defined) |
Clause Reference(s) | 6.3.2.5, 8.5.2.8, 9.4.2.6
Source (company - Author) | Spirent - Jacob Wieland

Summary | 0007738: TriMessage should be enhanced with a stream-like API

Description

At the moment, the contents of TriMessage can be accessed/configured via byte-arrays. While this approach is fine for short messages, it can become very tedious/inefficient in cases where the message is very large (several MB) is fragmented (arrives in chunks) needs to be processed in a stream-like fashion (as normally every codec does).
To that end, I would propose to add an API to TriMessage which allows fragmented filling of the message and one which allows accessing only parts of the message without having to copy the whole message first.
If that is the case, implementations of TriMessage can internally hold the data anyway they want as long as they allow access to it and potentially the whole data never needs to be copied.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR7738-TRI-1.docx (140,216) 18-07-2018 13:06 http://oldforge.etsi.org/mantis/file_download.php?file_id=3768&type=bug CR7738-TCI-1.docx (169,079) 18-07-2018 13:06 http://oldforge.etsi.org/mantis/file_download.php?file_id=3769&type=bug

Issue History
Date Modified | Username | Field | Change
19-12-2017 15:43 | Jacob Wieland - Spirent | New Issue |
06-06-2018 09:18 | Jacob Wieland - Spirent | Note Added: 0015109 |
16-07-2018 14:37 | Jens Grabowski | Assigned To | => Tomas Urban
16-07-2018 14:37 | Jens Grabowski | Status | new => assigned
18-07-2018 13:06 | Tomas Urban | File Added: CR7738-TRI-1.docx |
18-07-2018 13:06 | Tomas Urban | File Added: CR7738-TCI-1.docx |
18-07-2018 13:06 | Tomas Urban | Note Added: 0015158 |
18-07-2018 13:06 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
18-07-2018 13:06 | Tomas Urban | Status | assigned => confirmed
19-07-2018 09:09 | Jacob Wieland - Spirent | Note Added: 0015168 |
19-07-2018 09:09 | Jacob Wieland - Spirent | Status | confirmed => resolved
19-07-2018 09:09 | Jacob Wieland - Spirent | Fixed in Version | => Next version (to be defined)
19-07-2018 09:09 | Jacob Wieland - Spirent | Resolution | open => fixed
19-07-2018 09:09 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
16-01-2019 12:42 | Tomas Urban | Status | resolved => closed

Notes

(0015109)
Jacob Wieland - Spirent
06-06-2018 09:18

The same problems can also occur for any string-type, e.g. for octetstrings representing big files/attachments. Therefore, the OctetStringValue api (and similar) should als be enhanced with stream-based functionality so that it can be filled from a stream and also the contents read by a stream.
This allows implementations to more efficiently store the data dependent on the memory-management of their platform (chunked, file-based etc.) and thus allows handling of much larger strings than is often possible until now.

(0015158)
Tomas Urban
18-07-2018 13:06

Proposal uploaded. Please check.

(0015168)
Jacob Wieland - Spirent
19-07-2018 09:09

changes are fine