Forum


Notice to all users

We are migrating towards a new forum system located at community.teamspeak.com, as such this forum will become read-only on January 29, 2020

Results 1 to 9 of 9
  1. #1
    Join Date
    January 2010
    Location
    Germany
    Posts
    2,029

    "One Click Install" - Some Improvements

    The current implementation of the "One Click" Install for Addons, Translations, Icons, etc. is extremely limited if not almost useless.

    The one and only thing it does currently is to free the average User from needing to know where he installed his TS3 to and from copying a (few) File(s).

    What it should do:
    • Autodetect Client Architecture
    • Autodetect Operating System (if its ever to be released on Platforms other than Windows)
    • Automatically extract the necessary files only (for plugins) (on 64bit Linux only extract 64bit .so, Win 32 only extract 32bit DLLs etc.)
    • Allow for any additionally required Files to be included in the Package and extract them aswell.
    • Remove the limitation on SubDirectories allowing any subdirectory of the client Installation Folder to be used; possibly even new ones
    • Extract Root Level Files aswell (except for package.ini) (included in above two points but just to be sure)
    • Possibly the ability to display an EULA which you have to accept in order to install.
    • Some sort of Validity Verification. (File hasnt been changed since created by the Author and was in fact created by displayed Author)


    Some Points are obviously more important than others but in its current implementation its mostly useless and doesnt give that much of an advantage over plain rar/zip Files.
    Last edited by SilentStorm; June 21st, 2011 at 06:14 PM.

  2. #2
    Join Date
    May 2007
    Location
    Eastern NC
    Posts
    1,801
    I think a great addition would be that if the client is running and has the local query plugin running that the package installer can ask the client to stop the plugin, then update the plugin and then tell the client to reload all plugins and restart the updated plugin if it was running before. This will remove the need for the average user to manually perform those steps.

    I'm not sure I agree with getting rid of the folder restrictions, I think it is a appropriate to restrict that some.

  3. #3
    Join Date
    June 2008
    Location
    Krün, Germany
    Posts
    510
    Hello,

    late reply, but here it is...

    The one and only thing it does currently is to free the average User from needing to know where he installed his TS3 to and from copying a (few) File(s).
    That and nothing more was the initial goal of the project. So I'd say, task accomplished.

    After we saw how some people struggled to get TeamSpeak add-ons installed properly in the right place, we thought such a tool would help to make the progress easier. It wasn't meant to be something like NSIS for TeamSpeak Add-Ons. It was meant as an automatic un-zipper.

    Anyways, suggestions how to improve the thing are certainly good.

    Autodetect Client Architecture, Autodetect Operating System
    Sounds like a good thing to me. Even if this is nothing more than unzip-deluxe, telling the user that installing this Windows DLL on his Mac won't be overly useful would be certainly an improvement.

    if its ever to be released on Platforms other than Windows
    The plugin installer is also included in the Linux and Mac client installers

    Automatically extract the necessary files only
    While i see the point of this, it doesn't sound like a real improvement. A file called XXX_win32.dll would be ignored on a 64-bit Windows and vice versa.

    Remove the limitation on SubDirectories allowing any subdirectory of the client Installation Folder to be used; possibly even new ones
    This limitation was added with security in mind. What for do you need additional subdirectories? Add-ons are generally put into gfx, sound, plugins etc. I don't see the point of offering additional subdirectories. If I miss something here, tell me what you have in mind.

    Extract Root Level Files aswell (except for package.ini) (included in above two points but just to be sure)
    This was forbidded for security reasons as well. Allowing to overwrite the ts3client executable or one of the Qt libs sounds like a terrible idea to me. In my opinion addons should not touch the root directory at all.

    Possibly the ability to display an EULA which you have to accept in order to install.
    Possible, but I don't see this on high priority.

    Some sort of Validity Verification. (File hasnt been changed since created by the Author and was in fact created by displayed Author)
    We were already discussing on how to implement a mechanism for signing add-ons. We would very much like to add this feature.

    Generally some ideas are good, some I don't agree with. I could see the platform detection implemented for the TeamSpeak 3.0 release (no promise now, need to discuss this in the team first) and some others after 3.0. I hesitate from adding too much new stuff now risking to break something and further delay the 3.0 stable release.

    in its current implementation its mostly useless and doesnt give that much of an advantage over plain rar/zip Files.
    The usefulness of an unzip-deluxe can certainly be discussed. However, I am convinced it is an improvement for the more inexperienced user (and yes, personal family experience tells me that extracting an archive to some specific directory can be quite a task) and actually makes add-ons accessible for more people. And that's exactly what we had in mind.

  4. #4
    Join Date
    January 2010
    Location
    Germany
    Posts
    2,029
    Quote Originally Posted by PeterS View Post
    While i see the point of this, it doesn't sound like a real improvement. A file called XXX_win32.dll would be ignored on a 64-bit Windows and vice versa.
    I do realize that people can install 32bit Clients on 64bit Operating Systems, so this should take the Client Architecture in mind. And ignoring a win32.dll on a 64bit Client (and vice versa) would be a good thing since it would be useless anyway. I don't know if there is a (easy) way to detect whether a library / executeable is 64 or 32 but if there is that would be preferable over just judging from the filenames.
    Also currently one needs to create up to 6 different addon Files one for each OS & Architecture and Users still have to know what Client they installed. It would be much more comfortable for Developers and Users aswell to just have a single File that works everywhere (granted the Addon supports the specific OS / Architecture).
    If autodetecting the correct Files would be too complicated / impossible, you could even go and require them to be in specific Subfolders inside the Root of the Addon File.
    So it could look like this:
    Code:
    some_addon.ts3_addon
    *package.ini
    *mac64
    **plugins
    ***some_plugin.whatever_mac_uses
    *mac32
    .....
    *win64
    **plugins
    ***some_plugin.dll
    *linux64
    If there is no Folder for a specific OS / Architecture the Users System is not supported and the Installer should say so.

    Quote Originally Posted by PeterS View Post
    This limitation was added with security in mind. What for do you need additional subdirectories? Add-ons are generally put into gfx, sound, plugins etc. I don't see the point of offering additional subdirectories. If I miss something here, tell me what you have in mind.
    I don't know exactly anymore why I added that, might've just been an idea. I guess additional Subdirectories inside the Root could be pretty much avoided, but new Subdirectories within the above mentioned (currently implemented) Directories are certainly required, but I would think as its pretty much an unzip that this is already possible.


    Quote Originally Posted by PeterS View Post
    This was forbidded for security reasons as well. Allowing to overwrite the ts3client executable or one of the Qt libs sounds like a terrible idea to me. In my opinion addons should not touch the root directory at all.
    Obviously any client executeables would be off limits, maybe even the QtLibs if you prefer but in case of Plugins one might need to deliver additional Libraries which the Plugin depends on, which would need to go either into the client root or somewhere into %PATH%. In my opinion Client Root would be much more preferable.

    Quote Originally Posted by PeterS View Post
    Possible, but I don't see this on high priority.
    True thats certainly not a priority, but nice to have.

    Quote Originally Posted by PeterS View Post
    We were already discussing on how to implement a mechanism for signing add-ons. We would very much like to add this feature.
    Nice to hear I don't know if it is possible to use Certificates like you use for the client executeable (at least on Windows dunno about the other OS's) but if it is it might be a way.

    Quote Originally Posted by PeterS View Post
    I hesitate from adding too much new stuff now risking to break something and further delay the 3.0 stable release.
    While I can understand that, it might be a good idea to get some of this added before the Client officially goes final and people will be using this Installer for all sort of Addons. Especially lifting root limitations a bit, the Autodection Stuff and the Signing (though this might be tricky)

    Thanks for your Reply and considering the Suggestions

  5. #5
    Join Date
    December 2009
    Location
    Germany
    Posts
    289
    Some sort of Validity Verification. (File hasnt been changed since created by the Author and was in fact created by displayed Author)
    We were already discussing on how to implement a mechanism for signing add-ons. We would very much like to add this feature.
    There could be a first implementation with checking file-hashes. Hashed files can be checked, so every change can be detected.


    Extract Root Level Files aswell (except for package.ini) (included in above two points but just to be sure)
    This was forbidded for security reasons as well. Allowing to overwrite the ts3client executable or one of the Qt libs sounds like a terrible idea to me. In my opinion addons should not touch the root directory at all.
    As for me, this is a needed feature. Because i use the whole QT-Framework to implement my plugins, there are some parts of it, that needs to be shipped with the addons.
    Also there are some functions of the framework, that are not available in the included libs, so there also can be a need for me, to replace included parts of the framework. (I've had this with the windows-version, so this is not theoretical. Replaced with the file of the opensource-version without problem.)
    If you do that, there should be a backup of the replaced libs. Also every plugin-developer should know, why he replaces such a library, and should test all shipped platforms.

  6. #6
    Join Date
    October 2003
    Location
    Germany
    Posts
    2,527
    Quote Originally Posted by SilentStorm View Post
    Obviously any client executeables would be off limits, maybe even the QtLibs if you prefer but in case of Plugins one might need to deliver additional Libraries which the Plugin depends on, which would need to go either into the client root or somewhere into %PATH%. In my opinion Client Root would be much more preferable.
    I do not agree with you. All third party files required by a plugin should be located in the plugins directory (check the overlay plugin for example). I would not want any plugin to spread it's files all across my TeamSpeak 3 Client directory (or even my entire harddisk).

    Quote Originally Posted by Master_D View Post
    Also there are some functions of the framework, that are not available in the included libs, so there also can be a need for me, to replace included parts of the framework. (I've had this with the windows-version, so this is not theoretical. Replaced with the file of the opensource-version without problem.)
    So what happens when the TeamSpeak auto-update replaces those Qt files again during the next update? Your plugin will be broken. I repeat: it's not a good idea to allow the plugin installer to add/replace files in the client root directory and I would not use any plugin that requires me to do this.

    Also, I do not like the idea of having separate sub-directories for different platforms inside the archive since this could lead to redundant files. I'd prefer the way PeterS already suggested - using different file suffixes for platform specific files. For example:

    • some_file.ini (copy on any platform)
    • some_file_win32.dll (copy on 32-bit Windows only)
    • ...

    Signing addons is not important for TeamSpeak at all in my (personal) opinion. Take HTTPS for example... Most people don't care for trusted certificates at all. Many small companies and non-profit organizations use self-signed certificates and noone cares. You just hit the large red "open website anyway" button and you're done... Signing addons just means more work for the people creating them. The community does not care if they're signed or not - at least that's what I've been experiencing over the many years I've been in the TeamSpeak addons business.



    I agree that the current installer implementation is not - to say it with Guido Westerwaves words - "the yellow from the egg", but the devs achieved their main goal... for now.
    Last edited by ScP; June 25th, 2011 at 01:02 PM.

  7. #7
    Join Date
    January 2010
    Location
    Germany
    Posts
    2,029
    Quote Originally Posted by ScP View Post
    So what happens when the TeamSpeak auto-update replaces those Qt files again during the next update? Your plugin will be broken.
    A Client Update will likely require an updated Plugin anyway (API Change or Qt Lib Update). In cases were neither of those two occurs there is no need for the Updater to replace those Files and as such it shouldn't be done.

    Quote Originally Posted by ScP View Post
    Also, I do not like the idea of having separate sub-directories for different platforms inside the archive since this could lead to redundant files. I'd prefer the way PeterS already suggested - using different file suffixes for platform specific files.
    While possible it would require 32 & 64 Bit Versions of a Plugin to be linked differently. the 32bit Version would need to be linked to required_library_win32.dll and the 64 one to win64.dll instead of just linking to required_library.dll.
    To avoid duplicate Files inside the archive there could be an additonal Folder for Files that are the same in any OS / Architecture called something like global, all or whatever you prefer.


    Quote Originally Posted by Master_D View Post
    There could be a first implementation with checking file-hashes. Hashed files can be checked, so every change can be detected.
    Checking File Hashes requires User Interaction or rather the User to manually check the Hashes themselves which noone (or at least extremely few) people will ever do, in fact I think it would be a pretty safe bet to say that most dont even know how to do it in the first place.

    Quote Originally Posted by Master_D View Post
    As for me, this is a needed feature. Because i use the whole QT-Framework to implement my plugins, there are some parts of it, that needs to be shipped with the addons.
    Also there are some functions of the framework, that are not available in the included libs, so there also can be a need for me, to replace included parts of the framework.
    This is very true and I had it happen to me aswell.

  8. #8
    Join Date
    October 2003
    Location
    Germany
    Posts
    2,527
    Quote Originally Posted by SilentStorm View Post
    A Client Update will likely require an updated Plugin anyway (API Change or Qt Lib Update). In cases were neither of those two occurs there is no need for the Updater to replace those Files and as such it shouldn't be done.
    Not necessarily. The stable TeamSpeak 3 Client will at some point introduce some kind of backward compatibility mode for plugins. So developers will not need to update their plugins on each API version change.

  9. #9
    Join Date
    May 2007
    Location
    Eastern NC
    Posts
    1,801
    Any thought to my post about using the client query port if the user has it enabled in the client for the following?

    • check if TS3 client is running
    • request if plugin is installed and if running
    • if plugin is running stop it
    • extract plugin
    • if plugin was not installed call a reload all function of the plugins window
    • if the plugin was running at beginning of process restart it.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Replies: 2
    Last Post: July 8th, 2015, 11:39 AM
  2. [Evaluation] Add: Right-click users from "List All Clients" to view the "Server Groups Dialogue"
    By Morthawt in forum Suggestions and Feedback
    Replies: 1
    Last Post: February 22nd, 2014, 09:18 PM
  3. Right click option "Set Server Group" problem
    By Kazed in forum Permission System
    Replies: 2
    Last Post: December 26th, 2012, 12:43 PM
  4. [Suggestion] Right-Click: Move User to Channel "XY"
    By Billy_the_Puppet in forum Suggestions and Feedback
    Replies: 8
    Last Post: July 2nd, 2012, 09:32 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •