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
