Tasks #631

Make revisions for each IDL file available at runtime

Added by J. Wienke about 8 years ago. Updated almost 6 years ago.

Status:FeedbackStart date:10/14/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Build System
Target version:Robotics Service Bus - rsb-1.0

Description

Also as:
  • preprocessor declarations for C++
  • XML file or comparable for use outside of target languages or in external tools.

Related issues

Related to Robotics Systems Types - Tasks #601: Consolidate RST Types Resolved 09/30/2011

History

#1 Updated by J. Wienke about 7 years ago

I think this is not necessary anymore now that we have a complete project versioning scheme. Any objections to close this?

#2 Updated by J. Moringen about 7 years ago

+1

#3 Updated by J. Moringen about 7 years ago

Another argument against relying on RST to do its own versioning may be the following RETF recommendation which may not yet be publicly available (@Ingo: or is it?):

RD: 8
Title: Uniform referencing of Robot Data Message Types
Date: 
Author: Ingo L├╝tkebohle
Type: General
Content-Type: text/x-rst
Created: 2012-07-07

#4 Updated by S. Wrede about 7 years ago

Even if we have a versioning scheme for a complete RST library, I'd still argue for keeping versioning information in or with the IDL files. An exemplary, IMHO non-esoteric use case, for this is working with seralized recorded data where one may need to know the exact IDL version or to build generic tools which may operate on RST types but independent of a specific RST library version.

#5 Updated by J. Moringen about 7 years ago

Sebastian Wrede wrote:

Even if we have a versioning scheme for a complete RST library, I'd still argue for keeping versioning information in or with the IDL files. An exemplary, IMHO non-esoteric use case, for this is working with seralized recorded data where one may need to know the exact IDL version or to build generic tools which may operate on RST types but independent of a specific RST library version.

I thought the agreement for these cases was unconditionally including the content of the relevant type definitions (as opposed to their versions) and using the above mentioned RETF recommendation for compatibility checks.

#6 Updated by S. Wrede about 7 years ago

@Jan: Can you shortly explain what the role of the RETF "recommendation" would be here?

#7 Updated by J. Moringen about 7 years ago

Sebastian Wrede wrote:

@Jan: Can you shortly explain what the role of the RETF "recommendation" would be here?

The recommendation describes how the content of type definitions can be reduced to something like

magnet:?xt=urn:sha1:6FQLLAPYV6I6L5FJ7UINUWGGHEM5PBHA&dn=Twist.msg

Such a hash could be used for compatibility checks when exactly identical versions of a type definition are required.

Regarding my argument above: if the recording/replay tools need to store/retrieve the complete type definition anyway, they can generate these hashes on the fly as needed. Thus, in the recording/replay case, having a version is not necessary.

The situation would be different if we decided to rely on e.g. Protocol Buffer's backwards compatible schema changes. But I think we decided against that option.

#8 Updated by J. Wienke almost 6 years ago

  • Status changed from New to Feedback

Since we have versions now: is this still required at all?

#9 Updated by J. Moringen almost 6 years ago

For easier debugging, it could make sense to somehow attach git commits to data type definitions as part of the build process. With respect to the above discussion, this would allow generating URIs like:

magnet:?xt=urn:sha1:6FQLLAPYV6I6L5FJ7UINUWGGHEM5PBHA&dn=Twist.msg&v=7988b329

instead of just
magnet:?xt=urn:sha1:6FQLLAPYV6I6L5FJ7UINUWGGHEM5PBHA&dn=Twist.msg

In any case, we should probably think about these issues as part of the (potential eventual) conversion to Rosetta Stone Project.

#10 Updated by J. Moringen almost 6 years ago

  • Category set to Build System
  • Target version set to rsb-1.0

Also available in: Atom PDF