David,
You are absolutely right about that.
And I guess you are the first one who tried to think about using
saHpiMyEntityPathGet() function. :)
Suggest to create bug ticket in OpenHPI SF tracker.
We have very limited time frame for 3.0.0 release to include this fix.
So lets target it for 3.1.0.
Anton Pak
On Sat, 24 Sep 2011 01:23:54 +0400, David McKinley <[email protected]>
wrote:
> Hello,
>
> As I've gotten more familiar with OpenHPI, I've come across something
> that looks wrong, and I'm wondering if there has been some discussion
> about it in the past. Specifically, saHpiMyEntityPathGet() seems to be
> handled by the hpi daemon, returning an entity path that is configured
> in openhpi.conf for the daemon. It makes perfect sense that the entity
> path to return is a configuration item - but this API is supposed to
> return the entity path of where the application that links with the HPI
> library is running.
>
> Since applications running on various different entities - different
> blades, for example - can all connect to the same HPI daemon, there
> needs to be a way for those different applications to get different
> entity paths returned as a result of making this call. The easiest way
> to accomplish this would be to make the entity path to return be part of
> the openhpiclient.conf file rather than the daemon configuration. A
> much more complicated way would be to let the daemon figure out which is
> the appropriate entity path to return by somehow identifying the client
> making the request (by source IP address, or maybe some initial
> information exchanged when a session is established). I'm not sure that
> there is any particular advantage to this latter approach, though.
>
> In any case, having a single entity path configured in the daemon to
> return to any client request would not seem to accomplish the purpose of
> the saHpiMyEntityPathGet() API.
>
> David
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
