1

Progress

  • Deciding the file structure and import schema.
    As for now, decided to create a Monitor class for creating a monitor object that is responsible for storing plugin metadata and persisting usage metrics between consecutive electron API calls. More is discussed about the class members in subsequent points.

    packages
│   .
└───app-desktop
│   │
│   └───services
│   │  │
│   │  └───plugins
│   │  │   │
│   │  │   └───resource-monitor
│   │  │   │    │  `Monitor.ts`
│   │  │   │    │  `runner.ts`

  • The Monitor class is scaffolded as follows now:

    export class Monitor {    
 private _pluginStore: PluginDetails[];
 constructor() {
     this._pluginStore = [x];
 }
 addPlugin(osPId: number, plugin: any) {
     this._pluginStore.push({osPId, plugin});
 }
 getPlugin(osId: number) {
     return this._pluginStore.find(p => p.osPId === osId);
 }
 get pluginStore() {
     return this._pluginStore;
 }
}

  • The usage metrics is fetched using the ElectronApp.getAppMetrics() method. Reference
    It is then paired with the plugin metadata from the plugin object that is passed into run() function in PluginRunner.ts.
    Thus, a complete PluginDetails object is formed, and appended to _pluginStore each time a new plugin is started using the run() method.

Plans

  • Updating _pluginStore using a member function, this involves:

    • Fetching latest resource usage from the Electron API.
    • Checking for removed or newly added plugins and updating accordingly.

  • Accessing the Monitor object created in runner.ts in the GUI of the electron app, and displaying updated information.

Problems

  • I could not figure out how to make my test plugin use a certain (relatively large) amount of memory for a long time, as any unused variable is likely being deallocated by the garbage collector.
    I tried to loop over a large array of strings to prevent this, however, infinite looping eventually crashes my device by using too much CPU.
2

Thanks for the update. I couldn't find your plan over the coming weeks, do you have it somewhere? I'm wondering in particular your plan for releases - it would be best to split this project into multiple pull requests and aim, for example, to first release the backend, then the frontend, etc. Could you point me to your plan?

I think your weekly reports should give an overview of what you've been doing at a high level rather than go straight into coding details, because to be honest I can't make sense of almost anything in your code samples but that's probably because it needs to be looked at from a complete pull request.

One thing I'd say is the addPlugin/getPlugin functions are an indication that you are maintaining a list of plugins. But the app already has a list of plugins, and we generally don't want to have two lists of the same thing as it will need be kept in sync and is error prone. But again without seeing the rest of the code it's hard to tell if it makes sense or not.

3

it would be best to split this project into multiple pull requests and aim, for example, to first release the backend, then the frontend, etc.

This is the idea, I will open a draft PR soon (this week), that contains some backend part including the API call functions. Once opened, I will link it here in the replies.

I think your weekly reports should give an overview of what you've been doing at a high level rather than go straight into coding details,

Sure, will keep the reports high level for the coming weeks.

But the app already has a list of plugins, and we generally don't want to have two lists of the same thing as it will need be kept in sync and is error prone.

The list of plugins currently maintained will need to be extended for that purpose to accomodate the metrics, but again, this is a discussion that can be done in the draft PR thread.