Feature #2227

Symlinks/Aliases for Scopes

Added by C. Leichsenring over 4 years ago. Updated over 3 years ago.

Status:FeedbackStart date:04/21/2015
Priority:NormalDue date:
Assignee:C. Leichsenring% Done:

0%

Category:Protocol
Target version:rsb-1.0

Description

For various reasons it would be useful to make the same informer have multiple scopes, i.e. de facto symlinks or aliases for scopes. Example use cases would be:

  • provide a list of services or devices by human-readable name and number
  • list services by different criteria
  • provide different formats under different scopes but link to a default scope
  • .... basically every reason why one would want symlinks in file systems, too

Related issues

Related to Robotics Service Bus - Tasks #2559: Scope renaming New 02/16/2012

History

#1 Updated by J. Moringen over 4 years ago

  • Status changed from New to Feedback
  • Assignee set to C. Leichsenring
  • provide a list of services or devices by human-readable name and number
  • list services by different criteria
  • provide different formats under different scopes but link to a default scope
  • .... basically every reason why one would want symlinks in file systems, too

I'm not sure I understand these use-cases. Can you describe one of them in more detail?

Also, would it be necessary to support these scope aliases efficiently by building support into the core and network protocols or would forwarding events from one scope to another by a dedicated component be good enough?

#2 Updated by C. Leichsenring over 4 years ago

I don't think this feature would be all that useful if there still was a preferred scope for performance reasons. Other than during lookup, I think the performance should be the same, just as it is for actual symlinks.

It wasn't just me who has raised this issue but I'm going to use one of my use cases because I know them in more detail: Let's say there are a couple of scopes that provide the same audio source in different formats.

/some/source/of/audio/16000Hz/16bit/LE/
/some/source/of/audio/32000Hz/16bit/LE/
/some/source/of/audio/48000Hz/16bit/LE/
/some/other/source/of/audio/16000Hz/16bit/LE/
/some/other/source/of/audio/32000Hz/16bit/LE/
/some/other/source/of/audio/48000Hz/16bit/LE/

You might also want to provide the unmodified audio as a default:

/some/source/of/audio/default/
/some/other/source/of/audio/default/

This could then be a symlink to /..../48000Hz/16bit/LE/. Furthermore, it might be useful to have another set of symlinks that looks like this:

/audio/sources/by/channel/1
/audio/sources/by/channel/2
/audio/sources/by/channel/3
...

These would in turn be symlinks to the original sources that are named by location ... or vice versa.

Especially with the lack of globbing in scopes, such setups with aliases could solve some practical problems that arise.

#3 Updated by J. Moringen over 4 years ago

C. Leichsenring wrote:

I don't think this feature would be all that useful if there still was a preferred scope for performance reasons. Other than during lookup, I think the performance should be the same, just as it is for actual symlinks.

Making this efficient would be a lot harder than just making it possible.

It wasn't just me who has raised this issue but I'm going to use one of my use cases because I know them in more detail: Let's say there are a couple of scopes that provide the same audio source in different formats.

[...]

the example is clear, thanks.

Especially with the lack of globbing in scopes, such setups with aliases could solve some practical problems that arise.

What would globbing in scopes do?

#4 Updated by C. Leichsenring over 4 years ago

J. Moringen wrote:

What would globbing in scopes do?

It would allow to code all possible information one might want to filter for in a scope and then just search for all scopes that contain say */audio/out/*/channel* or whatever. This would blow up scope names but probably provide alternatives for many of the use cases above ... as long as they were considered at scope naming time ;)

#5 Updated by J. Moringen over 3 years ago

#6 Updated by J. Moringen over 3 years ago

  • Target version set to rsb-1.0

Also available in: Atom PDF