Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007738Part 06: TTCN-3 Control InterfaceNew Featurepublic19-12-2017 15:4316-01-2019 12:42
ReporterJacob Wieland - Spirent 
Assigned ToTomas Urban 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.9.1(ongoing) 
Target VersionNext version (to be defined)Fixed in VersionNext version (to be defined) 
Summary0007738: TriMessage should be enhanced with a stream-like API
DescriptionAt 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.
TagsNo tags attached.
Clause Reference(s)6.3.2.5, 8.5.2.8, 9.4.2.6
Source (company - Author)Spirent - Jacob Wieland
Attached Filesdocx file icon CR7738-TRI-1.docx [^] (140,216 bytes) 18-07-2018 13:06
docx file icon CR7738-TCI-1.docx [^] (169,079 bytes) 18-07-2018 13:06

- Relationships

-  Notes
(0015109)
Jacob Wieland - Spirent (reporter)
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 (developer)
18-07-2018 13:06

 Proposal uploaded. Please check.
(0015168)
Jacob Wieland - Spirent (reporter)
19-07-2018 09:09

 changes are fine

- 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

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker