You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After several years of releasing v3, its about time for me to release v4. I am now thinking of adding the following two features
to be able to have platform specific information
add optimization arguments to some function calls.
In addition, I would like to revisit and take in v4 labeled issues and PRs.
1. platform specific information
gopsutil is intended to be a platform independent library. However, there are always issues and PRs that request the inclusion of information that exists only on certain platforms. We would like to respond to this as follows.
For example, the following struct is currently defined. This definition is defined in the common file host.go.
type TemperatureStat struct {
SensorKey string `json: "sensorKey"`
Temperature float64 `json: "temperature"`
High float64 `json: "sensorHigh"`
Critical float64 `json: "sensorCritical"`
}
For all such structures, add a Specific() function in each individual platform file, such as host_linux.go
It might look like this.
type TemperatureStatLinux struct {
Min float64
Max float64
Crit float64
Alerm float64
}
func (s Foo) Specific() (TemperatureStatLinux, error) {
return TemperatureStatLinux{Min: 100}, nil
}
To use platform specific information, you have to write something like s, err := tempreture.Specific(). This is a bit tedious, but the intention is to make it clear that this part is platform-dependent.
I am sure there are other implementation ideas. Comments would be appreciated.
2. resolving performance issues
Add arguments to some APIs that were known to have performance issues but were left in place because of potential compatibility breakage.
Other issues with the performance label will be looked at carefully.
I was looking for a way to add a flag in ctx that would not break the API, but after some experimentation I decided that it would be less confusing to add it explicitly as an argument. I think it would be difficult to determine later if there is a problem.
Schedule
IMPORTANT NOTICE: I can only work on gopsutil mostly on weekends.
We will be calling for features on this issue for a while now, and by mid-December we will decide which features we want to include and set a release schedule. It will probably be after February 2024.
However, I am having physical problems at this moment. Depending on how it goes, there may be a further delay.
The text was updated successfully, but these errors were encountered:
After several years of releasing v3, its about time for me to release v4. I am now thinking of adding the following two features
In addition, I would like to revisit and take in v4 labeled issues and PRs.
1. platform specific information
gopsutil is intended to be a platform independent library. However, there are always issues and PRs that request the inclusion of information that exists only on certain platforms. We would like to respond to this as follows.
For example, the following struct is currently defined. This definition is defined in the common file
host.go
.For all such structures, add a
Specific()
function in each individual platform file, such ashost_linux.go
It might look like this.
To use platform specific information, you have to write something like
s, err := tempreture.Specific()
. This is a bit tedious, but the intention is to make it clear that this part is platform-dependent.I am sure there are other implementation ideas. Comments would be appreciated.
2. resolving performance issues
Add arguments to some APIs that were known to have performance issues but were left in place because of potential compatibility breakage.
For example,
Other issues with the performance label will be looked at carefully.
I was looking for a way to add a flag in ctx that would not break the API, but after some experimentation I decided that it would be less confusing to add it explicitly as an argument. I think it would be difficult to determine later if there is a problem.
Schedule
IMPORTANT NOTICE: I can only work on gopsutil mostly on weekends.
We will be calling for features on this issue for a while now, and by mid-December we will decide which features we want to include and set a release schedule. It will probably be after February 2024.
However, I am having physical problems at this moment. Depending on how it goes, there may be a further delay.
The text was updated successfully, but these errors were encountered: