11 article, at that time in the system integration, in fact, the idea of the time I still pondering, but later did not do system integration, but also have no opportunity to go deep to solve the problem.
= = = Text = =
A large part of the work that has been done in the project is about integrating the equipment. In order to facilitate the expansion to support more manufacturers of equipment, but in this process encountered a very headache, here I describe the problem, you are welcome to discuss.
Problem Description:
The so-called device integration, in most cases can be simplified for the integration of the SDK (this is more convenient, sometimes we prefer to directly integrate the protocol, but manufacturers have to consider). In view of this situation, our system uses the more typical plug-in design idea, encapsulates the functionally consistent device as a dynamic shared library of the unified interface, the runtime dynamically loads the call according to the database configuration, and the host software itself provides a set of interfaces for the underlying dynamic library to callback to obtain the necessary information.
I have described the problem to this extent, and it is estimated that many people are already giggling-yes, the dynamic library version problem ...
It should be said that in most cases this plug-in mechanism can be very good to meet the requirements of device integration, and can be easily implemented across platforms (this is important), but in one case, is to use the same shared library in a process, but the attempt to load two versions. At this point, the situation becomes very chaotic. Look at the Picture: (The tool is humble, the arrow I did not draw, probably the meaning should all understand)
The problem is very clear: now the embedded equipment manufacturers, but like the mobile phone industry, there are many manufacturers are "cottage machine", that is, based on embedded solutions to do two times the development of products (such as the domestic Ucos and Huawei HiSilicon program). For some complex functions such as decoders, the solution provider provides the host computer development package in the form of a dynamic library, which is the module of the factory bottom library in the diagram, and then the device manufacturer encapsulates the SDK to invoke these dynamic libraries. If you want to integrate two manufacturers of equipment A and B in one software, both manufacturers use a brand of hardware solutions, but the version is different, the problem arises. At this time the underlying library file name is the same, but the version is not the same, a process does not have to load two versions of the underlying library. If the solution provider does not have full version compatibility, there must be a device that cannot be used.
I have tried to solve this problem in two ways:
method One:Very wretched method. At that time the customer's platform for Win32, equipment are legacy equipment, manufacturers can not find, in order to quickly solve the problem I directly with UltraEdit open a Device SDK file to the inside of the call file name string changed a name, and then the underlying library also changed a name, the problem solved ... Later I have been not too relieved, afraid of problems, fortunately, there has been no problem. Later asked colleagues they said they have done so ... 囧
Method Two:In the design of a new version of the software, on the one hand, the standardization of the industry, regional industry standards have emerged, on the other hand, the new system focused on the overall solution, not for the old project transformation, this problem is not taken seriously. But I have a hunch that business-based considerations are sure to happen. I experimented with a way to encapsulate this piece of equipment into another process, interact with the main program, or another process to implement a portion of the interface, directly embedded in the main program interface (like SMPlayer). I made a prototype program on Windows, the functionality is fine, but the final version of the software does not consider this scenario. The main reason is that the mechanism and the main program of the mechanism is very different, packaged together is not easy, on the other hand to consider cross-platform, on the Linux platform to do the performance is not good, there is no way to optimize, and even some functions can not be achieved (after studying these are actually concluded).
At present, I do not have a very good solution to the problem, only to deal with the characteristics of the project to solve each. It should be said that the cause of the problem and technology is not related, mainly because the specification is not in place, the manufacturers fragmentation, blindly pursue "large integration", the lack of attention to usability. This problem is not enough, but it is often the "non-intellectual problem" most troubling people. It may be inappropriate to say that this is a problem, even if it brings a little bit of air.
[old article move] headache problem of plugin software design and possible solution idea
