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 > > ------------------------------------------------------------------------------ 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
