Hello: PCman: I could help you to compile MoonLightDE just tell me what's wrong. Right now I'm reworking the core in order to make it more friendly with the lxde technologies, I also have in mind to rebase our modules to the lxqt applications so we will be able to exchange patches.
About the C++ Micro Services library, it is used mainly to communicate the components. At the beginning of my research I was implementing a traditional Qt plug-in system but i found that this approach doesn't takes care of the communication between plug-ins and also doesn't offer a proper tracking system. In examples to be more explicit: - In the traditional approach is easy to communicate a plug-in with the main application but, how do you communicate two plug-is? You will need a registry of the instances provided by the plug-ins and the interfaces that they implements, and this is precisely one of the things that C++ Micro Services does. It uses the concept of service which is formed by an object, an interface and a set of properties used to describe the service. Whit this element you can found objects created by other modules in a simple manner. - But what happens when a module is unloaded or an object created by it is destroyed? With the Qt approach this will result in an segmentation fault or an null pointer exception when a module that uses the functionalities provided by other tries to use it. Whit Cpp Micro Services you can avoid this kind of failures by using the services trackers, this constructs keeps you updated with the state of a services so if it goes out of memory you will noticed. As you can see Cpp Micro Services is needed in order to keep our software robust and avoid the problems that brings using modules (plug-ins). About the forking, i think it is a good idea in order to keep the compatibility between the two approaches. Best Alexis López Zubieta MoonLight Development Team University of Informatics Sciences El 08/07/14 04:59, PCMan escribió: > Some updates. > Instead of doing some experiment, I tried to test MoonLightDE since it > did quite similar things. > However, I failed to get all of the components compiled correctly. > I'll try to fix them when I have time to see how it performs. > After a quick skim of the source code of MoonLightDE, I noticed that > it makes extensive use of C++ Micro Services library > (CppMicroService). Alexis, what's the benefit of using that? I found > it a little bit more complicated than needed? > I have another thought about the module architecture. > We can make them modules while retaining the stability of the original > multi-process architecture. > Just do "fork()" from the main process before loading the module, and > the components can be run in different processes, just like they're > now. So the crash of one component does not affect the other one. > This is actually what kdeinit process does. > If we add an option to turn off the "fork()" call, then all components > can run in the same process. > So we can switch between single process and multi-process > architectures on-the-fly with an runtime option. > Forking different components form the same core process is totally > different from launching different binaries. > When all of the components are forked from the same process, > relocation of dynamic libraries only happen "once" and this is exactly > how kdeinit speed up startup of KDE. > With this, we can solve three problems with the same solution. > 1. speed up startup but keep current multi-process architecture (by > forking from the main process) > 2. optional support of a single-process architecture with the same > code base (even more speed up and resource sharing) > 3. Sharing code with MoonLightDE becomes even easier (actually, we > even share the same goal if we do this) > > Users and developers who don't want a single-process mode can keep > using multiple process, and still benefit from a faster startup due to > kdeinit-like design. > Users who have limited resource can turn on the experimental > "single-process" option and avoid the fork() call. All modules then > stay in the same process. > What about the new proposal? > > Cheers! >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft
_______________________________________________ Lxde-list mailing list Lxde-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxde-list
