- it was configured with the very same openhpi.conf. There was no openhpiclient.conf that days.
Multi-domains appeared in 2.8 and domain configuration were in openhpi.conf
- yes, the very same plug-ins I attached the explaining (hope so) picture. The openhpi daemon is - openhpid.cpp - main function that creates daemon instance and parsescommand line agruments. It also creates instances of TCP server (listen for new connection, accepts incoming connection, serves connections). A thread is created for any new connections. The thread reads requests from the socket, demarshals it and passes it to the rest of the code.
Then it marshalls and sends reply.The rest of the code is Lib#2. It is linked statically into openhpid nowadays.
And it was possible to have it as a part of HPI application before.
Anton Pak
On Mon, 16 Aug 2010 14:22:51 +0400, Kleber, Ulrich (NSN - DE/Munich)
<[email protected]> wrote:
Hi Anton, I need a bit more of explanation here for the Lib#2. - How is it configured (openhpi.conf /openhpi.client.conf) - Are there plugins? If there are plugins, isn't Lib#1 = Lib#2 plus subordinate-plugin? In that case the subordinate plugin would just be what we currently do in the marshalling? Cheers, Uli-----Original Message----- From: ext Anton Pak [mailto:[email protected]] Sent: Monday, August 16, 2010 12:19 PM To: OpenHPI-devel Subject: Name collision issue for daemon and baselib Hello! While discussing the plug-in for subordinate OpenHPI we have faced API name collision: - openhpid defines saHpiXXX and oHpiXXX functions - libopenhpi.so also defines these function So it is hard to use libopenhpi.so from a plug-in code since it works inside openhpid process. The first idea to resolve it was the idea of renaming functions in openhpid. Say instead of saHpiSessionOpen we will have oHpidSessionOpen (other naming schemas are also options). I prepared a patch for this renaming. It was really huge. And it also broke make distcheck. As usual. Michael will be excited. The I suddenly have realized that the decision of using the same names was not an oversight. Long time ago we had two options for HPI library: one is the library that talked to OpenHPI daemon via RPC, and another one is the library that just performed OpenHPI daemon responsibilities (daemonless). So the picture was o) HPI App ->(linked)-> Lib #1 ->(RPC, TCP)-> OpenHPI daemon or o) HPI App ->(linked)-> Lib #2 Lib #2 included all OpenHPI daemon code except transport and marshalling. And it provided the same interface to an HPI App: a set of saHpiXXX and oHpiXXX function. So a saHpiXXX function in base lib is RPC call for the saHpiXXX function in OpenHPI daemon. Lib #1 and Lib #2 also shared the same name - libopenhpi.so. This option was disabled several years ago. So the questions are: - Should this renaming be performed or better to find another way? - Should we still care of the daemonless OpenHPI library? Anton Pak
<<attachment: daemonless.png>>
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Openhpi-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openhpi-devel
