Bug #1408
Converter registration should be possible without rewriting default participant configuration
Status: | Resolved | Start date: | 02/11/2013 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | J. Wienke | % Done: | 100% | |
Category: | Python | |||
Target version: | rsb-0.9 |
Description
I currently have the problem that a library I am using in my code (XTT) is registering some converters for the datatypes it uses. Since in Python this is currently only possible by rewriting the default participant config (the docs recommend calling rsb.setDefaultParticipantConfig(rsb.ParticipantConfig.fromDefaultSources())
after registering the converters), this is what XTT is doing internally (albeit still with the old rsb.__defaultParticipantConfig = ...
syntax).
Now in my code (e.g. in some unit tests), I explicitly set a default participant config, but this gets completely overwritten as soon as I call XTTs initialization code. And since this is the only documented way of registering converters, I don't really blame XTT for doing it like that.
In the end, registering new converters in Python should be possible without completely rewriting the default configuration, i.e. by appending to it (or doing whatever the other languages are doing for this purpose).
Associated revisions
Implement lazy converter map preparation.
So far, inside the participant configuration, the converter map was prepared
once initially with the first access to the participant config and afterwards
loaded from a cached variable. As a consequence it was impossible to add a
converter to the global converter map without regenerating the whole
ParticipantConfig. This, however, had the drawback that previous manual
modifications to the configuration were erased. With this change the converter
map for a new participant is created in a lazy fashion each time a converter
map for a participant is requested. Hence, new converters can now be added to
the global converter map and are automatically available for any new
participant.
- rsb/__init__.py: Implemented lazy loading of converter map
- test/coretest.py: Unit test adde to verify the behavior
refs #1408
Update example for converter registration.
Calling setDefaultParticipantConfig is not required anymore.
refs #1408
Update python converter registration.
With the lazy way of creating converter maps for individual participants it is
not required anymore to manually recreate the global participant configuration.
- Remove instructions to recreate the configuration
- Add a note to explicitly warn about this behavior.
refs #1408
Enable converter registration without changes to ParticipantConfig
Make the creation of ConverterMap instances dynamic so that new converters can
be added to the global map all the time without requiring a newly generated
default participant configuration.
fixes #1408
Merge branch 'bug-1408'
Update python converter registration.
With the lazy way of creating converter maps for individual participants
it is
not required anymore to manually recreate the global participant
configuration.
- Remove instructions to recreate the configuration
- Add a note to explicitly warn about this behavior.
refs #1408
Adapt manual to python converter registration changes
Reflect the lazy creation of converter maps for individual participants.
- Warn about previous usage
refs #1408
Merge branch 'bug-1408'
History
#1 Updated by D. Klotz about 11 years ago
Are there any ideas on how and when this could be changed? This makes it really hard to write rsb-using python libraries, since they can only register the converters by replacing the participant config (and thereby overwriting any changes to it that e.g. the library-using client-program might have done before that).
Maybe someone could shed some light on why this is done differently in Python than e.g. in C++, where AFAIK you can register a new converter without replacing the default participant config?
#2 Updated by J. Wienke almost 11 years ago
- Target version changed from rsb-0.7 to rsb-0.9
We should not forget to fix this in 0.9. It's a severe restriction.
#3 Updated by J. Wienke almost 11 years ago
- Assignee changed from J. Moringen to J. Wienke
#4 Updated by J. Wienke almost 11 years ago
- Status changed from New to In Progress
#5 Updated by J. Wienke almost 11 years ago
- % Done changed from 0 to 80
I have pushed respective changes to the implementation and the manual. Can someone please review them and verify the intended behavior?
#6 Updated by J. Wienke almost 11 years ago
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
Applied in changeset rsb-python|commit:8ec3b1e64674144c7f1165338d82ce35dbf6d447.