Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: TCI/TRI compliance

TCI/TRI compliance 02 Feb 2005 14:18 #6793

Hi all,

I have a theoretical question, about any implementation of TCI and TRI.

ES 201 873-5 and 6 defines mappings, among others, to Java and C. It seems that
a really working implementation of these interfaces cannot be achieved
implementing only the defined functions and types, but other auxilliary stuff is
also needed (registering objects, memory management, etc.).

Question: to what extent may these interfaces be extended with additional
elements, in order to remain TCI/TRI compliant?

Best regards,
Jozsef Hosszu EXT
Siemens Com MN RD E 3
The administrator has disabled public write access.

TCI/TRI compliance 02 Feb 2005 15:12 #6794

Jozsef,

I can tell at least for C mapping.

A working implementation of TRI mapping can be made highly
standard-compliant. Additional elements include adapter
initialization and setup, what is beyond the scope of the
TRI standard.

The same for TCI-TM.

A working TCI-CD implementation can be made standard-compliant
in that respect that it will not do things against the standard.
However, the standard defines memory management in a rather
vague way, so this needs to be defined precisely in order to
work. Even this could be considered as filling in the gap rather
than introducing additional elements.

The only real extension that could be needed in TCI-CD interface
is something of this kind:

void tciReleaseValue(TciValue inst);

The semantics of this function could include deallocation of
memory and data associated with the value in question and
contained subvalues, but even this function is not needed in
practice in most cases, if you take into account typical usage
scenarios (tciEncode(), tciDecode()) and apply common sense
to ownership conventions for parameters and return values of
interface function calls.

Hope this helps,

Alexey Mednonogov
OpenTTCN Oy

Hosszu Jozsef EXT wrote:

>Hi all,
>
>I have a theoretical question, about any implementation of TCI and TRI.
>
>ES 201 873-5 and 6 defines mappings, among others, to Java and C. It seems that
a really working implementation of these interfaces cannot be achieved
implementing only the defined functions and types, but other auxilliary stuff is
also needed (registering objects, memory management, etc.).
>
>Question: to what extent may these interfaces be extended with additional
elements, in order to remain TCI/TRI compliant?
>
>Best regards,
>Jozsef Hosszu EXT
>Siemens Com MN RD E 3
>
>
The administrator has disabled public write access.

TCI/TRI compliance 02 Feb 2005 15:26 #6795

Dear Jozsef,

from the interface perspective the necessary functionality can be
implemented quite well with the operations standardized. What is out of
scope are the management aspect, basically, how all the parts are glued
together. This is true for all TRI and TCI interfaces. In addition you
have in C the question of memory management.

But to specify this type of functionality requires different
functionality at the interfaces for each language mapping. Thus the
standard covers only the common TTCN-3 functionality.

The typically solution, at least with our tools providing Java and C
interfaces is, to offer additional interfaces, which are more language
related. The standardized ones are kept unchanged.

I hope this answers part of your questions.

Best regards,

Theo Vassiliou
Testing Technologies

Hosszu Jozsef EXT wrote:
> Hi all,
>
> I have a theoretical question, about any implementation of TCI and
> TRI.
>
> ES 201 873-5 and 6 defines mappings, among others, to Java and C. It
> seems that a really working implementation of these interfaces cannot
> be achieved implementing only the defined functions and types, but
> other auxilliary stuff is also needed (registering objects, memory
> management, etc.).
>
> Question: to what extent may these interfaces be extended with
> additional elements, in order to remain TCI/TRI compliant?
>
> Best regards, Jozsef Hosszu EXT Siemens Com MN RD E 3
>
>
The administrator has disabled public write access.

TCI/TRI compliance 04 Feb 2005 13:50 #6796

Dear Sirs, Theo, Alexey, Vesa-Matti,

Thanks for the answers, now the picture is clear.

Regards,
Jozsef Hosszu

>
Original Message
> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of
> Theofanis Vassiliou-Gioles
> Sent: Mittwoch, 2. Februar 2005 16:27
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: TCI/TRI compliance
>
>
> Dear Jozsef,
>
> from the interface perspective the necessary functionality
> can be implemented quite well with the operations
> standardized. What is out of scope are the management aspect,
> basically, how all the parts are glued together. This is true
> for all TRI and TCI interfaces. In addition you have in C the
> question of memory management.
>
> But to specify this type of functionality requires different
> functionality at the interfaces for each language mapping.
> Thus the standard covers only the common TTCN-3 functionality.
>
> The typically solution, at least with our tools providing
> Java and C interfaces is, to offer additional interfaces,
> which are more language related. The standardized ones are
> kept unchanged.
>
> I hope this answers part of your questions.
>
> Best regards,
>
> Theo Vassiliou
> Testing Technologies
>
> Hosszu Jozsef EXT wrote:
> > Hi all,
> >
> > I have a theoretical question, about any implementation of TCI and
> > TRI.
> >
> > ES 201 873-5 and 6 defines mappings, among others, to Java
> and C. It
> > seems that a really working implementation of these
> interfaces cannot
> > be achieved implementing only the defined functions and types, but
> > other auxilliary stuff is also needed (registering objects, memory
> > management, etc.).
> >
> > Question: to what extent may these interfaces be extended with
> > additional elements, in order to remain TCI/TRI compliant?
> >
> > Best regards, Jozsef Hosszu EXT Siemens Com MN RD E 3
> >
> >
>
The administrator has disabled public write access.
  • Page:
  • 1

FacebookTwitterGoogle BookmarksRedditNewsvineTechnoratiLinkedin