Add ability to manual reload PluginsManifest data

[jjw24]

Add ability to manual reload the plugins manifest

[taooceros]

Is it possible to fire up the progress bar when doing the job?

[jjw24]

the reload has been quick for me, is it different for you? also it is not async, so program pauses and query box is hidden

[taooceros]

the reload has been quick for me, is it different for you? also it is not async, so program pauses and query box is hidden

Oh I misunderstand how this will be done, I thought it is like a query selected result. It is quick for me, since the file is not large.
However, the Task won't be waited, this runs actually async, which won't block the method that triggered it. So, potentially it will not finish even though the reloading says it has been reloaded.

Though I don't like the synchronous block, should we put a Wait() that here? Although I think loading pluginManifest won't be slow since plugins.json is small.

[jjw24]

Will do

[taooceros]

I suddenly have a though based on this code. Regarding to #233 and the later part #195 that I wants to make the plugins to have async model so that they can utilizes the async/await model and CancellationToken from mainThread.
We can create a new async interface for plugin instead of creating default implementation for existing interface, which is not elegant and a bit dirty.
Regarding the IReloadable, we can also create a new Interface like IAsyncReloadable, like what Microsoft has added, IAsyncDisposable so that plugins won't worry about the async model they are using, and this will handling IO transmission better like the "Http.Get" here.

[jjw24]

I suddenly have a though based on this code. Regarding to #233 and the later part #195 that I wants to make the plugins to have async model so that they can utilizes the async/await model and CancellationToken from mainThread.
We can create a new async interface for plugin instead of creating default implementation for existing interface, which is not elegant and a bit dirty.
Regarding the IReloadable, we can also create a new Interface like IAsyncReloadable, like what Microsoft has added, IAsyncDisposable so that plugins won't worry about the async model they are using, and this will handling IO transmission better like the "Http.Get" here.

sounds good, lets do this in a seperate pr.

[taooceros]

I suddenly have a though based on this code. Regarding to #233 and the later part #195 that I wants to make the plugins to have async model so that they can utilizes the async/await model and CancellationToken from mainThread.
We can create a new async interface for plugin instead of creating default implementation for existing interface, which is not elegant and a bit dirty.
Regarding the IReloadable, we can also create a new Interface like IAsyncReloadable, like what Microsoft has added, IAsyncDisposable so that plugins won't worry about the async model they are using, and this will handling IO transmission better like the "Http.Get" here.

sounds good, lets do this in a seperate pr.

Of course, I will add it as part of #195.

[jjw24]

Can we do a fresh pr? That one should just be kept for upgrading result list referring, otherwise hard to test and review

[taooceros]

Can we do a fresh pr? That one should just be kept for upgrading result list referring, otherwise hard to test and review

Hmmm maybe you are right, although I originally want to solve the Explorer plugin issues and cancellation sync, so I create it based on that branch. I will rebase that toward dev.