Provide some means to determine Client API Version

[SilentStorm]

Currently you can determine to API Version by calling ts3Functions.getAPIVersion(), however in order to do this you actually have to have the same API Version as the Client already as otherwise you won't be able to call that function. (which makes this function useless btw. as you could just use whatever you defined which is faster and less code)

It would be much more preferable to determine the Client API Version inside ts3plugin_init() for example by changing the Function to ts3plugin_init(const int apiVersion) so you would have the current Client API Version to check against yourself.

The goal is to have the ability to check for an updated version of the Plugin which supports the current Client API Version.

[T.S. Excreta]

This would be very useful.

[SilentStorm]

actually I just found out that my original Suggestion doesn't seem to work anymore.
With previous Client Versions I think there were a couple of Functions called prior to ts3plugin_apiVersion() however with the latest Client that function appears to be the first one called and if it doesn't match the client's internal API Version it gets unloaded instantly.
Having the parameter passed this this specific function is obviously a bad idea as it would circumvent the whole API Version System entirely.

However I still feel that it is necessary to be able to determine the Client's API Version in some way before ts3plugin_apiVersion() gets called.
A possible way would seem to be adding a new function that would be called before the API Version is checked (ts3plugin_update(const int apiVersion)?). You could even make it optional so there is no need to change existing Plugins and Developers who want to provide some means to check for a compatible Version after a Client Update could take advantage of it. This should even be possible to be implemented without raising the API Version (if desired) as it should be just as much as adding a check if the plugin exports that function and if it does call it prior to calling ts3plugin_apiVersion().

[dante696]

The idea is not bad, but it is also not perfect.
- The client would take longer time to connect on start. Because it needs to chec kfor an updated version.
- Our client prevents, that an outdated plugin does not crash our client. This is the reason, why outdated plugins are disbaled.
The plugin needs to load, to get updated and this stands in conflict with our API check.

This is not on our To-Do and it is not rejected. A Developer is informed about it and made a note for himself.
This idea is complicated and needs to be discussed.

[SilentStorm]

The idea is not bad, but it is also not perfect.
- The client would take longer time to connect on start. Because it needs to chec kfor an updated version.

I never said or claimed it would be perfect, merely the best I came up with thinking about it for like 2 minutes

The Client wouldn't be affected much really. It's a simple function that gets called which doesn't take long at all.
As far as speed for connecting on start is concerned: Not sure if this would cause any adverse Problems but why not connect anyway and do the plugin loading / checking in a separate Thread?

- Our client prevents, that an outdated plugin does not crash our client. This is the reason, why outdated plugins are disbaled.
The plugin needs to load, to get updated and this stands in conflict with our API check.

Outdated Plugins already get loaded briefly (as stated in the OP that used to be different and thus even worse as far as preventing crashes by outdated Plugins goes) and with this Suggestion it would be in memory for just a few moments longer. You wouldn't even need to allow access to the Framework or anything fancy at all. Just a Function that gets called containing the Clients' API as an Argument so Developers could check for updates. It usually shouldn't take long at all to complete the function.

If you really wanted to you could also only call that Function if the Plugin's API Version does NOT match the Client's one. (Keep calling ts3plugin_apiVersion() as first function, if it does not match call ts3plugin_update(ClientAPIVersion) (if exported by the Plugin) and then unload the Plugin after that function completed, otherwise continue as usual.)
Not sure if this is possible right now but if you are that concerned about loading speed force unload the Plugin some time after the update function got called (500ms should be more than sufficient).

Since the update Function would only be called after a Client Update which changed the API Version (if you only call it if the API does not match) it should not be that much of a problem if the first Client Start after an update takes one or two seconds more than it used to. Most people won't even notice.

This is not on our To-Do and it is not rejected. A Developer is informed about it and made a note for himself.
This idea is complicated and needs to be discussed.

What exactly is complicated about this Idea if you don't mind me asking?

[T.S. Excreta]

The idea is not bad, but it is also not perfect.
- The client would take longer time to connect on start. Because it needs to chec kfor an updated version.
- Our client prevents, that an outdated plugin does not crash our client. This is the reason, why outdated plugins are disbaled.
The plugin needs to load, to get updated and this stands in conflict with our API check.

This doesn't make much sense since the plugins are checked and loaded WELL before the client actually tries to connect.

Tue. Jan 24, 2012 12:56:07 PM		Info	TeamSpeak 3 Client 3.0.3 (2012-01-20 10:49:07)	
Tue. Jan 24, 2012 12:56:07 PM	Direct Sound	Debug	setting timer resolution to 1ms	
Tue. Jan 24, 2012 12:56:07 PM		Info	Registering plugin command id: {06474108-ef7c-40eb-b10d-809a44547df4} appscanner_plugin	
Tue. Jan 24, 2012 12:56:07 PM	Windows Audio Session	Devel	DeviceDeleteList::waitForDeletes - enter	
Tue. Jan 24, 2012 12:56:07 PM	Windows Audio Session	Devel	DeviceDeleteList::waitForDeletes - leave	
Tue. Jan 24, 2012 12:56:07 PM	ClientUI	Info	Qt version: 4.7.2	
Tue. Jan 24, 2012 12:56:07 PM	ClientUI	Info	Using configuration location: C:/Program Files/TeamSpeak 3 Client/config/ts3clientui_qt.conf	
Tue. Jan 24, 2012 12:56:07 PM	Input	Info	Input device name: Mouse	
Tue. Jan 24, 2012 12:56:07 PM	Input	Info	Input device name: Keyboard	
Tue. Jan 24, 2012 12:56:08 PM	ClientUI	Info	Last update check was: Tue Jan 24 10:54:36 2012	
Tue. Jan 24, 2012 12:56:08 PM	ClientUI	Info	Connect to server: server.ts3.server	
Tue. Jan 24, 2012 12:56:08 PM	ClientUI	Info	Trying to resolve server.ts3.server	
Tue. Jan 24, 2012 12:56:08 PM	ClientUI	Info	Lookup finished: server.ts3.server 9999 server.ts3.server 0 0	
Tue. Jan 24, 2012 12:56:08 PM	ClientUI	Info	Resolve successful: server.ts3.server:9999	
Tue. Jan 24, 2012 12:56:08 PM	ClientUI	Info	Checking blacklist	
Tue. Jan 24, 2012 12:56:08 PM		Info	Trying to resolve blacklist server	
Tue. Jan 24, 2012 12:56:08 PM	ClientUI	Info	Blacklist check ok	
Tue. Jan 24, 2012 12:56:08 PM	ClientUI	Info	Initiating connection: server.ts3.server:9999 server.ts3.server	
Tue. Jan 24, 2012 12:56:08 PM	Windows Audio Session	Devel	DeviceDeleteList::waitForDeletes - enter	
Tue. Jan 24, 2012 12:56:08 PM	Windows Audio Session	Devel	DeviceDeleteList::waitForDeletes - leave	
Tue. Jan 24, 2012 12:56:08 PM	Windows Audio Session	Devel	DeviceDeleteList::waitForDeletes - enter	
Tue. Jan 24, 2012 12:56:08 PM	Windows Audio Session	Devel	DeviceDeleteList::waitForDeletes - leave	
Tue. Jan 24, 2012 12:56:08 PM	Windows Audio Session	Debug	WAS::openDevice-enter	
Tue. Jan 24, 2012 12:56:08 PM	Windows Audio Session	Debug	WAS Buffer size: 882	
Tue. Jan 24, 2012 12:56:08 PM	Windows Audio Session	Debug	WAS::openDevice-leave	
Tue. Jan 24, 2012 12:56:08 PM	PreProSpeex	Info	Speex version: speex-1.2beta3	
Tue. Jan 24, 2012 12:56:08 PM	Windows Audio Session	Debug	WAS::startDevice-enter	
Tue. Jan 24, 2012 12:56:08 PM	Windows Audio Session	Debug	WAS::startDevice-leave	
Tue. Jan 24, 2012 12:56:08 PM		Info	Blacklist server resolved	
Tue. Jan 24, 2012 12:56:08 PM		Info	Data sent to blacklist server	
Tue. Jan 24, 2012 12:56:08 PM	ClientUI	Info	Connect status: Connecting	
Tue. Jan 24, 2012 12:56:09 PM	ClientUI	Info	Connect status: Connected	
Tue. Jan 24, 2012 12:56:09 PM	ClientUI	Info	Connect status: Establishing connection	
Tue. Jan 24, 2012 12:56:09 PM	ClientUI	Info	Connect status: Connection established	
Tue. Jan 24, 2012 12:56:09 PM		Info	Data received from blacklist server: 1,	
Tue. Jan 24, 2012 12:56:10 PM	EncodeCelt	Info	CELT bitstream version: 0x80000010

[SilentStorm]

If Plugins get loaded and checked well before even trying to connect to any Server that has been setup to be connected to when the Client starts it does make _some_ sense.
Apparently they are concerned that calling one simple Function would delay the startup process for too long and hence would delay the Client attempting to connect to the "Connect on Startup" Servers. However as I (tried to) explain above I don't think this is going to be an issue... checking for Updates really does not take that much time.

[T.S. Excreta]

If Plugins get loaded and checked well before even trying to connect to any Server that has been setup to be connected to when the Client starts it does make _some_ sense.
Apparently they are concerned that calling one simple Function would delay the startup process for too long and hence would delay the Client attempting to connect to the "Connect on Startup" Servers. However as I (tried to) explain above I don't think this is going to be an issue... checking for Updates really does not take that much time.

Yeah, but it doesn't make enough sense to warrant not having the feature at all. That was why I chose the words "...much sense..." in my reply.

Basically if the plugin is registered (I highlighted the events in my log above) before a connection is even attempted, then it won't delay connection startup at all. Also, as you said, it would have minimal (at worst) effects on how long it takes the client to actually launch and get itself into a ready state.

In other words... I fully support your idea. I have several plugins I have made for my guilds and gaming clans which would GREATLY benefit from this ability.

[dante696]

Quick (and ignoring your discussion): It's on devs note, but not rejected or todo.

[PeterS]

Generally having plugins which update themselves would certainly be a cool feature for all those users, who upgrade their (stable channel) TeamSpeak client and suddenly all plugins don't work anymore, without being involved in plugin development themselves.

The general problem I have with calling some update function in the plugin before initializing is that this could block the client during startup. Update server not reachable? Update host DNS lookup fails? Then this function call would block until connection timeout, which can be a couple of seconds. Of course plugins could do an async lookup or put a sync lookup inside a threat, but that's not guaranteed to be the case.

Another problem I see with updating plugins from the plugin code, as long as the plugin is loaded, Windows will refuse to overwrite the plugin DLL. So just some messagebox pointing the user to a webpage with the updated plugin download might be an idea as well?

Current order of function calls when loading a plugin:

- Call ts3plugin_apiVersion (Mismatch? -> Unload DLL)
- Call ts3plugin_requestAutoload
- Call ts3plugin_setFunctionPointers (now ts3Functions.getApiVersion is available)
- Call ts3plugin_init

Not calling init when the API version mismatches still sounds good to me, as there is no need to initialize plugin stuff (like the Lua interpreter for example) if the plugin gets unloaded soon again.

Above mentioned optional update messagebox might be added below the call to ts3plugin_apiVersion (only called if the api mismatches). That messagebox would of course need to be non-modal to avoid the client blocking.

Summarized, I do understand and basically agree with what you want to do, but a *good* solution would require some more thoughts, so I took the opportunity to throw in my part to the discussion.

[SilentStorm]

The general problem I have with calling some update function in the plugin before initializing is that this could block the client during startup. Update server not reachable? Update host DNS lookup fails? Then this function call would block until connection timeout, which can be a couple of seconds. Of course plugins could do an async lookup or put a sync lookup inside a threat, but that's not guaranteed to be the case.

I agree that you could not possibly count on any and all Plugin Developers to do the Update check "properly" so it wouldn't stall the client (for too long at least).
Not sure but wouldn't it help to run the update Check in a separate Thread (if possible)?

Another problem I see with updating plugins from the plugin code, as long as the plugin is loaded, Windows will refuse to overwrite the plugin DLL. So just some messagebox pointing the user to a webpage with the updated plugin download might be an idea as well?

That is indeed a Problem but one that neither of us can change, so we'll have to live with that and make the best of it. But it probably won't have much impact since the currently loaded Plugin will get unloaded as its incompatible. After that the DLL is no longer loaded and thus can be overwritten.
Personally I was thinking about downloading the new Plugin Version and inform the User that there is an update available for his new Client with some Info on how to install the new Version. If possible maybe even run the Plugin Installer automatically so there is as little as possible User Interaction required.

Current order of function calls when loading a plugin:

- Call ts3plugin_apiVersion (Mismatch? -> Unload DLL)
- Call ts3plugin_requestAutoload
- Call ts3plugin_setFunctionPointers (now ts3Functions.getApiVersion is available)
- Call ts3plugin_init

Not calling init when the API version mismatches still sounds good to me, as there is no need to initialize plugin stuff (like the Lua interpreter for example) if the plugin gets unloaded soon again.

I agree that calling init if the Plugin is already doomed to be unloaded again is wasted effort.
But as stated in the OP ts3Functions.getApiVersion() is a useless Function as it is only available after you already know the Plugin has the same API as your Plugin and since you know that for a fact you could just use PLUGIN_API_VERSION (if you used/defined it) or the returnvalue of ts3plugin_apiVersion() if you need the API Version for anything. (Less Code and much faster)

Above mentioned optional update messagebox might be added below the call to ts3plugin_apiVersion (only called if the api mismatches). That messagebox would of course need to be non-modal to avoid the client blocking.

So you want to add another Function that gets called but only have it display some sort of basic Messagebox that you create?
If so then it would likely end up beeing a function like ts3plugin_name() which just returns some string wouldn't it?
Not sure I'd like that very much, as all you could do is return a URL to a basic download Page which would need to be hardcoded into the Plugin. URLs change and with TS Update Frequency reducing it becomes increasingly more likely that by the time the API Version changed the old URL is no longer valid.
It would still be an improvement over the current situation though.

Summarized, I do understand and basically agree with what you want to do, but a *good* solution would require some more thoughts, so I took the opportunity to throw in my part to the discussion.

Much appreciated.

[Screech]

Just a thought of mine. We already have the addons site. Why not add a function that TS3 client can call in the dll for getting a url to the plugins location on the addons site and have it check for updates for all plugins (match API or not). Run this check in a new thread after the client has loaded. If any of the plugins have a NEWER version on the addons site prompt the user with a window listing the updated plugins. Have check boxes so the user can selectively update some or all of the plugins with updates. If the API for the plugin on the addons site is mismatched to the client don't check the box (maybe highlight it red too). If the user selects update the client can manage downloading the update(s), stopping the selected plugin(s) if it is running, passing the downloaded file(s) to the package_inst program, and finally restarting the plugin(s).

If package_inst does not support a silent install mode this would be a good use for that parameter.

Well, that's my $0.02 on making it as easy as possible for the users.

[PeterS]

Those $0.02 sound good. Most of the UI could be integrated into the plugins dialog of the client, with perhaps a messagebox to notify the user once one or more plugin updates are available.

I think plugins updating themselves is not a good idea, it's better if the client does it while the plugin just provides its update URL. If that URL gets outdated, it's bad luck.

Regarding the function to get the client API version, yes that's indeed not necessary. I can kick that out the next time the API version changes, for now I won't do it as I doubt it's worth another API increase for 3.0.4 and that tiny function doesn't really disturb.

I will add this to our bugtracker, but it certainly won't be done for 3.0.4, which was planned as a bugfix release without new features, as that would delay the release too much.

Internal Ticket ID TS-828

[T.S. Excreta]

Those $0.02 sound good. Most of the UI could be integrated into the plugins dialog of the client, with perhaps a messagebox to notify the user once one or more plugin updates are available.

I think plugins updating themselves is not a good idea, it's better if the client does it while the plugin just provides its update URL. If that URL gets outdated, it's bad luck.

Regarding the function to get the client API version, yes that's indeed not necessary. I can kick that out the next time the API version changes, for now I won't do it as I doubt it's worth another API increase for 3.0.4 and that tiny function doesn't really disturb.

I will add this to our bugtracker, but it certainly won't be done for 3.0.4, which was planned as a bugfix release without new features, as that would delay the release too much.

Internal Ticket ID TS-828

I love your enthusiasm in this discussion, Peter. Just reading your words, it sounds like you really love what you do.

Even though this isn't my thread, thanks for such a lively discussion on it.

[Screech]

Just looked at the plugins site and realized it does not have an API field to input the current API of the plugin. So unless that is added you couldn't check that the available plugin's API matches the clients without downloading it, extracting the dll/so/dylib and querying it. Should be easy to add to the addons site and would make it easy to add an "up to date plugins only" filter that shows only plugins with an API that matches the client's on the downloads page while browsing for new plugins.