Robotics Systems Types

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

+1

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

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.

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.

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

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.

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

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.