Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Publishing an interface for other components (Read 866 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Publishing an interface for other components

Is their a way for components to register an interface for other components to consume dynamically?

I can do dynamic linking or COM but I prefer to go through the foobar2000 framework.

Re: Publishing an interface for other components

Reply #1 –
I've never done anything like it myself but you could look at musicmusic's SVG services component for an example.

https://github.com/reupen/svg-services

The API is exposed in this file which is the only file other projects need to include.

https://github.com/reupen/svg-services/blob/main/api/api.h

The main source is here...

https://github.com/reupen/svg-services/blob/main/foo_svg_services/main.cpp

And before you can consume it, you'd have to test for presence of the component using static_api_test_t<BLAH> -replace BLAH with whatever the service name is.

Re: Publishing an interface for other components

Reply #2 –
Quote from: marc2k3 on
I've never done anything like it myself but you could look at musicmusic's SVG services component for an example.

https://github.com/reupen/svg-services

The API is exposed in this file which is the only file other projects need to include.

https://github.com/reupen/svg-services/blob/main/api/api.h

The main source is here...

https://github.com/reupen/svg-services/blob/main/foo_svg_services/main.cpp

And before you can consume it, you'd have to test for presence of the component using static_api_test_t<BLAH> -replace BLAH with whatever the service name is.

Thx. I'll have a look at it.

Re: Publishing an interface for other components

Reply #3 –
Back in the early days of my Waveform Seekbar it was actually split into two components, a foo_wave_cache component that dealt only with scanning of tracks and database manipulation and a foo_wave_seekbar component that provided a seekbar UI element on top of it. I ended up removing it as it was too much work for my small set of users to keep the versions synched up and there was never any other consumers of the waveform infrastructure.

There's still some traces of it in the codebase as wave::cache Cache.h exposes a narrow DLL-friendly interface. It leverages the same kind of service infrastructure as foobar2000 itself, it's just that the services are provided from the component rather than the core program or a core component.

My interface has since the merge grown some functions that are not safe to use across DLL boundaries as they use C++ standard library types like std::function. Those aren't safe as the DLL involved may use different C++ runtime versions or have their own statically linked runtime.

The important things about such an API is that you need to design it in a similar way to the services that foobar2000 provides where you need to interface stability is important. If you modify the interface too much, it should probably be a _v2 or a new interface, as such a binary interface must be stable.
Stay sane, exile.
 

Re: Publishing an interface for other components

Reply #4 –
Thanks for the reply.

I'm more worried about thread safety for what I have in mind. I'm still in the prototyping phase.