Thanks for the feedback, Sascha. Forwarding to insight-developers... On Tue, Dec 18, 2012 at 6:38 PM, Sascha Zelzer <[email protected]> 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 ([email protected]) 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 >> <[email protected]> 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 >>> > _______________________________________________ Powered by www.kitware.com
Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-developers
