Rocon Resource Universal Identifiers [Platform Tuples]

[stonier]

@bit-pirate @jack-oquin @jihoonl @hughie @dwlee @piyushk

PlatformInfo doesn't fit its purpose very well any more. The orchestration and interactions black boxes meant it's had to evolve as we go...and it even got an Icon attribute as well, which is redundant for many use cases. The last couple of demos has seen some spaghetti creep in too - quick and dirty functions hither and thither. So I'm going back to the drawing board and cleaning up. Let's nail the definition, centralise the relevant code and stabilise.

First proposal is in the following pull requests:

• [x] https://github.com/robotics-in-concert/rocon_msgs/pull/69
• [x] https://github.com/robotics-in-concert/rocon_multimaster/pull/245
• [x] https://github.com/robotics-in-concert/rocon_app_platform/pull/135
• [x] https://github.com/robotics-in-concert/rocon_concert/pull/174
• [x] https://github.com/robotics-in-concert/rocon_tutorials/pull/20
• [x] https://github.com/robotics-in-concert/rocon_qt_gui/pull/33

Summary:

• Code centralised in rocon_utilties.platform_tuples
  • PlatformTuple.msg added.
• PlatformInfo.msg composites this.
• All code switched to assume storage of PlatformTuple.msg types rather than strings.
  • Strings need an awful lot of validation checks at every step
  • Resetting parts of the string tuple is expensive, msg structure is not.
  • Easy enough to consume (from yaml) or produce (for logging) human readable strings on demand.
• Basic string representation example is ubuntu.precise.ros.turtlebot.dude

Next Step:

Jack has been talking about a proper uri for this. There was lots of discussion in this thread, e.g.

• concert client: ubuntu.precise.ros.turtlebot.dude -> rocon:///ubuntu/precise/ros/turtlebot/dude
  • the first posn could be utilised for a concert name: rocon://cybernetic_concert/ubuntu/precise/ros/turtlebot/dude
  • fits very well for requesting/sheduling resources, see current example of resource requirements
• concert client + rapp: rocon:///ubuntu/precise/ros/turtlebot/foo#rocon_apps/chirp
  • could be representative of a concert client executing a rapp, or a potential executable for the scheduler
• rapp: name->rocon_apps/chirp with platform_tuple dependency ->rocon:///ubuntu/*/ros/*/*
  • this would be expressed in .rapp files

I'm not fond of representing a rapp with rocon:///ubuntu/*/ros/*/*#rocon_apps/chirp. Another rapp with rocon:///windoze/*/opros/*/*#rocon_apps/chirp would be seen as a different rapp by the scheduler. All it needs to know is the rocon_apps/chirp in order to satisfy resource requests.

Along with python regex's to make wildcards possible.

Questions:

What are people's thoughts?

• Is PlatformTuple.msg as a rosmsg storage class suitable for both string representations?
• Is there a better msg representation?
• Are there any big pros or cons to using resource uri's?
• Are uri's inconvenient?
  • I find they are a bit more awkward to read/write than the dot representation
  • But I can't find a better reason not to use them.

[jack-oquin]

Note that the generic URI syntax seems to allow leaving out the first two '/' characters after the 'rocon:' when omitting the concert name ("authority" section). RFC-3986 states:

   The generic URI syntax consists of a hierarchical sequence of
   components referred to as the scheme, authority, path, query, and
   fragment.

      URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

      hier-part   = "//" authority path-abempty
                  / path-absolute
                  / path-rootless
                  / path-empty

   The scheme and path components are required, though the path may be
   empty (no characters).  When authority is present, the path must
   either be empty or begin with a slash ("/") character.  When
   authority is not present, the path cannot begin with two slash
   characters ("//").  These restrictions result in five different ABNF
   rules for a path (Section 3.3), only one of which will match any
   given URI reference.

So, these two strings would be equivalent:

rocon:///hardware_platform/client_name/application_framework/operating_system#rapp_name
rocon:/hardware_platform/client_name/application_framework/operating_system#rapp_name

[stonier]

So this syncs with using rocon:/turtlebot like you have in the comments of the message file update?

[jack-oquin]

Yes. I believe that is a valid interpretation of the generic URI syntax rules. It is worth noting because the "authority" section (concert_name) will almost always be empty. I wrote the EBNF examples above with that in mind.

I'd like a second opinion on that interpretation, so please read RFC-3986 carefully and see if you agree.

[stonier]

On wikipedia:

The hierarchical part of the URI is intended to hold identification information hierarchical in nature. If this part begins with a double forward slash ("//"), it is followed by an authority part and a path. If the hierarchical part doesn't begin with ("//") it contains only a path.

Also:

The path part, if present, may optionally begin with a single forward slash ("/").

That would also imply that we could do rocon:/turtlebot/dude and even rocon:turtlebot/dude. If I thought wikipedia was rigorous, I'd say their first statement implies that rocon:///turtlebot/dude is verboten.

Going back to RFC-396..I can't find anywhere that it actually supports wikipedia's interpretation. Example, in Section 3 the // is part of the hier-part but is not the authority.

Confusing point 1) The only references there are to no authority state how the ensuing path should look.

Confusing point 2) There is nothing saying the leading // in the hier-part can be optional, but an example, urn:example:animal:ferret:nose would imply thus.

The best notion of support to the idea of removing // is in their regex expression in appendix B. Specifically this part - (//([^/?#]*))? would imply that the // can be optional if there is no authority part.

Conclusion : I'd say it's not well-defined, but there is enough supporting evidence to drop it.

[jack-oquin]

It probably is well-defined, but RFC-3986 is using a slightly different (ABNF) notation.

I think both section 3 and the regexp (which is helpful), are saying that the authority element (which may be empty) is introduced by //. If it is missing, the // may also be omitted. The path element may not begin with //, but it may follow a third / after an empty // authority. A relative path is also allowed, but only if the authority and the leading slashes are omitted.

Those rules are rather complicated, hence the confusion. That is why I asked for a second opinion, in case I was reading it wrong.

[stonier]

Merged all the pull requests Jack. Shall we close this thread and open new discussions as we need?

[jihoonl]

android_remocon need upgrade?

[stonier]

Massively. I'm postponing that for a while while things are changing and just testing interactions with the qt programs.

[jack-oquin]

I am content to close this issue, as suggested. I reviewed the lengthy discussion above, and it looks like all the major points are resolved.

I will make the corresponding updates in a platorm_tuple_overhaul branch of the ROCON packages I am developing and link to this issue.

Please let me know when this overhaul is ready to merge into the main development branch.

[jack-oquin]

Please let me know when this overhaul is ready to merge into the main development branch.

I see that has already been done.