Hello, I spent some time reading through the documentation on the CppMicroServices module, but a few things are still not clear to me,
General: Note: By "MITK Module" I mean code that resides in the Modules/ folder of a MITK application, and is created by MITK_CREATE_MODULE(...). By CppMicroServices Module I mean what you would access via us::ModuleRegistry::GetModule(.... - Can I assume that the CppMicroServices "Module" is the same as MITK "Module"? Or are these two different concepts that share the same name? - Is every MITK module always a service? In my application I have one module that seems to not be a service. It has no activator code, and seems to be just an ordinary dll with header and cpp files. - Is every service a MITK module? GetModule(1): - In my code I see us::ModuleRegistry::GetModule(1)->GetModuleContext(); occasionally, I have checked which module GetModule(1) returns and it appears to be CppMicroServices. - Can I rely on Module 1 to always be CppMicroServices? - What determines the ID of this module? I would guess that code like this is getting some "global context" that MITK resides in, is this correct? The code then goes on to register additional services in that context. - If my guess is correct, is there a cleaner way to accomplish this, or is this the recommended method? Also, if the CppMicroServices module is a MITK module and also a manager of MITK modules, wouldn't that be a chicken and the egg situation? How is it itself loaded before the microservices microservice is loaded? I'm a bit curious to hear how this is managed. Contexts: - How many contexts are there? Exactly one on the entire PC, one per application / executable, or is there an unlimited number of contexts? - The documentation says "A module's execution context within the framework" -- what is the "framework"? Is this referring to some other class that exists as an instance that's created at some point when an MITK application starts up? - The documentation for the module context says it "can be used by the caller to act on behalf of this module", what does that mean? To me it implies that there is some global state linking modules together, or that modules are running on separate thread(s) from each other, but I have not seen this in the modules I've used, does anyone have an example of this? - Why would a caller need to act on behalf of a module, beyond the publicly available functions that the module's classes expose? Maybe our application is not making full use of this feature, because it seems like primarily we just create instances of objects from modules and use them like standard C++ objects, it sounds like there's some kind of hidden "module state" feature that I'm not aware of. - Is it possible to start more than one instance of a module or service? usServiceTracker: - What exactly is being tracked on the service by this class? Is this tracker class just here to manage the lifetime of an interface to a service? - There appears to be a "service modified" event, but what does it mean to "modify" a service? Is this event fired when any data managed by a service changes, or does this event get fired for "higher level" events like a service getting stopped or started? Thanks, - Alex
_______________________________________________ mitk-users mailing list mitk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mitk-users
