#1 Re: General Discussions & Feedback » Messaging between modules » 2015-06-25 17:35:58

Hi Sebastian,

your are right, there is no Event Admin implementation for CppMicroServices available. Currently, modules can communicate with each other only via custom services (except for the classic code sharing via linked modules, of course).

The CTK Plugin Framework contains an Event Admin implementation for both Qt4 and Qt5. For CppMicroServices, I once thought about taking the CTK Event Admin code and replacing the Qt bits by standard C++ plus a small threading library (e.g. tinythread) for cross-platform threading and synchronization support. However, I currently do not have resources left for doing so myself. Contributions are of course welcome :-)

#3 Re: General Discussions & Feedback » Discover module references » 2015-04-24 06:50:58

Hi,

in general, no.

The CppMicroServices library tracks only service usages but this requires clients to consistently use getService / ungetService calls.

Static library dependencies (when modules depend on exported symbols of other modules during link time) could be determined at runtime with some effort but it gets really complicated when libraries use dlopen and dlsym calls themselves. In the context of module unloading with CppMicroServices, you could make your life easier by only trying to unload modules which act as pure "providers", e.g. they only register services and don't export any symbols at all. By using hidden visibility (when using ELF shared libraries) and not exporting any symbols, other libraries cannot link to the module or discover symbols at runtime with dlsym. The registered service implementations can be used by other modules and the dynamics of the CppMicroServices library ensure that clients get notified about the service withdrawal when you unload the "provider module" (which should be possible at any point in time).

- Sascha

#4 Re: General Discussions & Feedback » Is it alright to publish CppMicroServices on Biicode? » 2015-02-21 13:39:42

Hi Azriel,

thanks a lot for the effort you put into this, it is highly appreciated. I have been very busy the last weeks so sorry for getting back to you so late.

I will look through your branch in detail the next week and probably get back to you with a few questions.

Thanks,
Sascha

#8 Re: Feature Requests » Querying module properties without loading the module » 2014-12-15 23:03:27

I like the idea in general but need to think more about the issues involved. Do you have a special use case in mind?

In the recent OSGi specs, there is a generic ReqCap model (requirements / capabilities) which I have been looking at and I am wondering if that would also "solve" our use cases. With such a mechanism, modules (auto-loaded or normal modules) would require specific capabilities in order to be resolved and these requirements would be matched by the framework against other installed libraries (or the framework itself, which could be configured with a certain set of capabilities). If the reqs are not met, the module would not be resolved and not be loaded at all.

Looking forward to your comments.

#10 Re: General Discussions & Feedback » Management of shared objects. » 2014-12-15 03:47:08

struct IFileProtocol
{
  virtual ~IFileProtocol() {}
  virtual void Foo() = 0;
};

class FileProtocolHandler : public IFileProtocol
{
private:

  us::ServiceTracker<IFileProtocol> m_FileProtocolTracker;

public:

  FileProtocolHandler(us::ModuleContext* context, /* service props if needed */)
   : m_FileProtocolTracker(context)
  {
    m_FileProtocolTracker.Open();
  }

  // IFileProtocol interface
  void Foo()
  {
    if(IFileProtocol* fileProto = m_FileProtocolTracker.GetService())
    {
      return fileProto->Foo();
    }
    else
    {
      // fallback / warning msg / etc
    }
  }
};

#11 Re: Feature Requests » Querying module properties without loading the module » 2014-12-15 02:21:33

Work is currently being done on the state machine for managing state transitions properly. There will also be a change in the initialization code for modules, making it more robust in terms of (static) initialization scenarios. There is not much left but 3.0 won't make it before Chirstmas, I'm afraid. I will post a status updated in mid-January about this topic.

#12 Re: General Discussions & Feedback » Is it alright to publish CppMicroServices on Biicode? » 2014-10-27 22:25:52

Thanks a lot for your efforts.

In general, I would suggest to only push releases to Biicode. Although the master contains only "release commits" since some time, I think it is best practice to push the latest release tag. As I am not really familiar with Biicode, I don't know their available policies about versioning though.

In which context are you referring to an "embedded use"? There is an internal CMake variable "US_IS_EMBEDDED" which is used if the source code is embedded in another larger project but this is all done automatically.

The caveat you are mentioning leads me to think about the header file directory layout for CppMicroServices modules. The next release will support multiple modules inside the CppMicroServices repository and header files will typically get installed in

/usr/include/cppmicroservices/core/Module.h
/usr/include/cppmicroservices/shell/ShellService.h
...

So, a user "cppmicroservices" on Biicode could make sense, with the sub-modules representing project names. Again, I don't know if Biicode can handle projects contained in the same repository. But the include directives would look the same in every project using CppMicroServices, irrespective of the fact if it uses Biicode or not.

#13 Re: General Discussions & Feedback » Building service/client modules with different, incompatible compilers » 2014-10-24 00:03:29

Thanks a lot for your input. While it is not on my short-term todo list, I will keep monitoring the CppComponents project and eventually contact its developer. The hourglass pattern you mentioned also looks promising to me (it actually was in my original list of possible approaches).

The approach with declarative services + C-style service interfaces (plus maybe a convenience header-only C++ interface wrapping the C-style interface) could work in a restricted scenario where modules communicate exclusively via service interfaces and do not make any CppMicroServices API calls at all. The declarative services module itself would take care of the service wiring by reading the xml files from the modules and taking care of the CppMicroServices API calls on behalf of the modules. Hence such modules would not have any linker dependencies to the CppMicroServices library (at least not to its C++ API). Dependencies to other modules would only involve the C API for the C-style service interface. Therefore no ABI incompatibilities would exist. Currently, the module initialization code would still force a linker dependency on the CppMicroServices library, but this is going to change soon. So far the theory...

In practice I would still be concerned about different runtimes needed by modules compiled with different compilers. E.g. on Windows, one would get dependencies to different versions of msvcrt.dll, msvcr*.dll, etc. libraries which use different heaps. Correct memory management across module boundaries would have to be enforced (at least in the service interfaces).

#14 Re: General Discussions & Feedback » Is it alright to publish CppMicroServices on Biicode? » 2014-10-23 16:41:44

Hi,

sure, go ahead and publish it. I am not really familiar with biicode, so I don't know how it handles versioning and updating the published project from one release to another.

Would you be willing to look into that and maybe publish new releases?

Thanks!

#20 Re: Feature Requests » Querying module properties without loading the module » 2014-09-08 23:44:05

I am not aware of any issues on iOS in this regard, but I also didn't try the system on this platform yet. The Mach-O object file format is used both on Mac OS X and iOS and by looking at its documentation, all sections and segments are specified in terms of offsets from the beginning of the file. The current development branch (containing the new resources system) also passes all tests on Mac OS X 10.7 (my test system). It should even work with universal binaries, by adding the blobs at the end of the final universal binary, effectively sharing the resources between all object files for different architectures.

#21 Re: Feature Requests » Querying module properties without loading the module » 2014-08-12 20:54:44

Okay, good to know.

In our case, we have a large code-base developed over more than 10 years which we are gradually moving to a more modular and service oriented architecture. So currently we mostly use module activators replacing static initialization code, the resources system, and at some places the service registry. Service usage is slowly increasing and I fully agree that after a certain threshold, managing service dependencies directly by using the framework API will become unmaintainable. We are just no there yet, but it needs definitely attention!

#22 Re: Feature Requests » Querying module properties without loading the module » 2014-08-12 20:11:44

To be honest, there is no specific due date for version 3.0. Almost all issues except for the resource loading feature have been resolved for 3.0. I did work on the resources system but couldn't find time to finish it yet. I am still aiming for a late September release though, after we got through all the testing for our own product using 3.0 features.

Config Admin is still high on the priority list (we have a few internal projects with requirements for such a service). Declarative Services on the other hand is something I would personally love to have, but its development is not directly driven by any of our current requirements. I also was not planning to couple the service implementations to the 3.0 release to no longer defer it. The development will very likely be based on the 3.0 release and either take place within the CppMicroServices project or get their own repository.

However, I am happy to incorporate external priorities into the planning process as far as possible.

#25 Re: General Discussions & Feedback » Usign QtClases as interfaces. » 2014-04-19 23:04:19

I am surprised that your initial approach with a marker interface did not work. Generally it should and there might have been just a small issue with your or the CppMicroServices code.

Also, my above example wasn't complete when using qobject_cast. Remember to use Q_INTERFACES in the implementing class and running moc on it (this is needed for the qobject_cast call):

struct IDesktopWidget {
};

US_DECLARE_SERVICE_INTERFACE(IDesktopWidget, "org.my-project.IDesktopWidget")

class MyDesktopWidget : public QWidget, public IDesktopWidget
{
  Q_OBJECT
  Q_INTERFACES(IDesktopWidget)

  // implementation goes here...
};

The US_DECLARE_SERVICE_INTERFACE acts as a replacement for the Q_DECLARE_INTERFACE macro and adds a CppMicroServices specific template specialization. With this approach, you don't need a virtual method in the interface (qobject_cast doesn't use RTTI).

Let me know if it doesn't work out.

Board footer

Powered by FluxBB