[Insight-developers] ITKv4 / ITK Factories and CppMicroServices library
Matt McCormick
matt.mccormick at kitware.com
Tue Dec 18 22:48:35 EST 2012
Thanks for the feedback, Sascha. Forwarding to insight-developers...
On Tue, Dec 18, 2012 at 6:38 PM, Sascha Zelzer
<s.zelzer at dkfz-heidelberg.de> wrote:
> Hi Matt,
>
> please see my comments inline.
>
>
> On 12/18/2012 09:10 PM, Matt McCormick wrote:
>>
>> I would be interested to get your opinion on the following issues:
>>
>> 1) Could we maintain a backwards compatible API with the ObjectFactory?
>
> Without having thought about all the details yet, I would say yes. The
> implementation of the itk::ObjectFactoryBase class could probably be
> modified to register and use corresponding "services" internally. But to
> make sure, we would have to prototype something.
>
>
>> 2) Would we *need* to use shared libraries? Could be maybe use some
>> CMake magic instead/as an alternative? Maybe it would be an option
>> for packages like Slicer to use the shared libraries. As it stands,
>> ITK can be built with all static libraries, which is a feature would
>> want to keep (nice for clusters, etc). Also, the only Module on
>> Windows that is built as a shared library is ITKCommon. I am not sure
>> how feasible it is to get all the IO modules to be shared....
>
> The CppMicroServices library explicitly supports static modules, see
> http://cppmicroservices.org/doc_latest/MicroServices_StaticModules.html.
>
>
>>
>> I will add it to the agenda for the Montreal, Hackathon tomorrow.
>>
>>
>> https://docs.google.com/document/d/1i2ibaZMS_vxzLocGVeElz6t5DVF7CWHfyFrB2WldF1c/edit#heading=h.r7h4uqn8p8ld
>
> Great, we are very interested about the feedback. I would also be available
> on Google Chat (sascha.zelzer at gmail.com) tomorrow for potential questions
> during the Hackathon.
>
> Here is some more background information about the library itself: As Jc
> said, the API of the library is considered stable and there is only one
> small feature missing which we want to get in before doing a 1.0 release.
> The planned feature is a very lightweight resources system allowing users to
> embed arbitrary resources into a module (similar to the Qt resource system
> but lighter) and retrieve the resource as an std::ostream object via a
> convenient API. After the 1.0 release, I plan to make the API even more
> compile-time type-checking friendly and remove the requirement of a common
> base class for service objects. This would then be version 2.0 and should be
> finished around March next year.
>
>
>>
>> I am also CC'ing the itk-developers mailing list. There are many
>> smarter people than myself that may have more ideas on this ;-).
>
> Thanks for your input! I kept the itk-developers list as CC but it will
> probably not arrive without a subscription. Please feel free to forward it
> if you think it is of general interest.
>
> Best,
>
> Sascha
>
>
>
>>
>> Thanks,
>> Matt
>>
>> On Mon, Dec 17, 2012 at 6:22 PM, Jean-Christophe Fillion-Robin
>> <jchris.fillionr at kitware.com> wrote:
>>>
>>> Hi Matt,
>>>
>>> Attending the CTK Hackfest in Bologna, I discussed with MITK folks about
>>> their experience with the ITK (IO) Factories. While the system in place
>>> gets
>>> the job done, they shared with me some of their concerns and helped me
>>> redacting the following text:
>>>
>>> Registering new overrides involves quite a lot of boilerplate code (the
>>> object plus a factory) and the usage is non-intuitive for beginners (this
>>> could be improved by more detailed Doxygen documentation for the
>>> ObjectFactoryBase::RegisterOverride method and a code example.
>>> The handling and prioritisation of multiple overrides for the same class
>>> type is difficult. ITKv4 seems to have added a position argument to the
>>> RegisterFactory method but the order returned by e.g. CreateAllInstance
>>> still depends on the registration order.
>>> Type checking must be done by the user. Object factories registered as
>>> overrides for certain class names may return any subclass of LightObject.
>>> Typos in the class name are hard to debug and actual class names and
>>> their
>>> override strings may get out-of-sync.
>>> The life-cycle of registered object factories is not communicated. While
>>> probably not in the original scope of ITK object factories, notifications
>>> about registered/unregistered factories at runtime would make sense for
>>> some
>>> use cases.
>>>
>>>
>>> While discussing, they introduced me with the cross-platform C++ library
>>> named “CppMicroServices”[1] that could help addressing some of the
>>> challenges encountered while using the current ITKIOFactory system.
>>>
>>> From the website:
>>>
>>> “The C++ Micro Services library provides a dynamic service registry based
>>> on
>>> the service layer as specified in the OSGi R4.2 specifications. It
>>> enables
>>> users to realize a service oriented approach within their software stack.
>>>
>>> The advantages include higher reuse of components, looser coupling,
>>> better
>>> organization of responsibilities, cleaner API contracts, etc.”
>>>
>>> This is a pure C++ implementation of the OSGi service model and does not
>>> have any third-party library dependencies.”
>>>
>>> The idea would be to leverage this library to provide either a
>>> replacement
>>> or an alternative system to register ITK IOPlugin. The following code
>>> snippets show the different approaches taken by ITK and CppMicroServices
>>> for
>>> “overriding” a class type :
>>>
>>>
>>> General (using itk::ImageIOBase as the “interface”)
>>> =======================================================
>>>
>>> namespace itk {
>>> class ImageIOBase : public LightProcessObject
>>> {
>>> // public interface
>>> // ...
>>> }
>>> }
>>>
>>> // The following macro allows type-safe APIs in CppMicroServices plus
>>> // the handling of versions for evolving interfaces
>>> US_DECLARE_SERVICE_INTERFACE(itk::ImageIOBase,
>>> “org.itk.ImageIOBase/1.0.0”)
>>>
>>> class MyImageIO : public itk::ImageIOBase
>>> {
>>> // implementation details
>>> // ...
>>> }
>>>
>>>
>>> ITK
>>> ===========================================================
>>>
>>> // usually one factory for each registered override
>>> class MyImageIOFactory : public itk::ObjectFactoryBase
>>> {
>>> typedef MyImageIOFactory Self;
>>>
>>> virtual const char* GetITKSourceVersion() const { … }
>>> itkFactorylessNewMacro(Self);
>>> itkTypeMacro(MyImageIOFactory, itk::ObjectFactoryBase)
>>>
>>> static void RegisterOneFactory()
>>> {
>>> MyImageIOFactory::Pointer myFactory = MyImageIOFactory::New();
>>> // Try to give it top priority
>>> itk::ObjectFactoryBase::RegisterFactory(myFactory,
>>> INSERT_AT_FRONT);
>>> }
>>>
>>> protected:
>>>
>>> MyImageIOFactory()
>>> {
>>> // use strings for class names
>>> this->RegisterOverride(“itkImageIOBase”, “MyImageIO”,
>>> “My custom image IO”, 1,
>>> itk::CreateObjectFunction<MyImageIO>::New());
>>> }
>>> };
>>>
>>> // Make sure to call
>>> // MyImageIOFactory::RegisterOneFactory()
>>> // somewhere. Can lead to subtle (de)initialization ordering
>>> // problems, especially in the context of static initializers.
>>>
>>>
>>> CppMicroServices
>>> ========================================================
>>>
>>> // One “activator” per shared library
>>> class MyActivator : public mitk::ModuleActivator
>>> {
>>> MyImageIO::Pointer m_MyImageIO;
>>>
>>> void Load(us::ModuleContext* context)
>>> {
>>> m_MyImageIO = MyImageIO::New();
>>> us::ServiceProperties props;
>>> // Give this service a ranking (priority) of “100”.
>>> // This can still be overridden, but does not depend on
>>> // the registration order.
>>> props[us::ServiceConstants::SERVICE_RANKING()] = 100;
>>> // No factories, register an instance of MyImageIO as a
>>> // a “singleton”. Service factories may also be used.
>>> context->registerService<itk::ImageIOBase>(m_MyImageIO, props);
>>> }
>>> }
>>> US_EXPORT_MODULE_ACTIVATOR(MyLib, MyActivator)
>>>
>>> Let’s also note that the library is API complete and is now used in
>>> projects
>>> like [2] and [3] and companies like [4]. The library also provides full
>>> life-cycle notifications for registered objects, an auto-load mechanism
>>> roughly similar to ITK, powerful service object queries, and puts an
>>> emphasis on the separation of interface and implementation.
>>>
>>> It would be great if we could engage discussion with the rest community
>>> regarding the current system and the possible adoption of a different
>>> mechanism. Considering that a ITK Hackfest dedicated to factory will
>>> happen
>>> later this week on Dec 19, it could be a good opportunity to discuss it.
>>>
>>> I will let you forward this email to the ITK developer list if you think
>>> it
>>> applies.
>>>
>>> Thanks,
>>> Jc
>>>
>>>
>>> [1] http://cppmicroservices.org/
>>>
>>> [2] http://www.mitk.org
>>>
>>> [3] https://github.com/Global-Vision-Systems/Ds4Cpp
>>>
>>> [4] http://www.global-vision-systems.com/index.php?Home
>>>
>>> --
>>> +1 919 869 8849
>>>
>
More information about the Insight-developers
mailing list