Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MGR: Client version check #1768

Merged
merged 8 commits into from
Jan 31, 2017
Merged

Conversation

AenBleidd
Copy link
Member

Reused existing mechanism of version check.
Manager will check for new version during connection to the client.
Default message about new version will be shown in notices tab.
Added menu to check new version manually. In this case user will see the message with check result.
Fixed issue with new version response parse.

It seems that this check will work if the client will check newer file version on start.
Client will check this even the last check was more that 14 days ago and on start only.
Client newer saves this information in its internal files  and never reread 'get_current_version.xml' between checks.
In any other cases result will be empty.
@AenBleidd
Copy link
Member Author

Fixed issue #1767 .

@AenBleidd AenBleidd mentioned this pull request Jan 25, 2017
@AenBleidd
Copy link
Member Author

@davidpanderson, @ChristianBeer, Could you please review this? Thanks

@adamradocz
Copy link
Member

It would be very nice an automatic update option as well which works like Windows Update. Download the update automatically and install it silently.
Is it possible?

@AenBleidd
Copy link
Member Author

@adamradocz, it is very dangerous to update app automatically. You can read more conversation here: #28

@davidpanderson davidpanderson merged commit 98d908d into BOINC:master Jan 31, 2017
@davidpanderson
Copy link
Contributor

Not sure we want version check that often but OK.

@AenBleidd AenBleidd deleted the ClientVersionCheck branch January 31, 2017 10:37
@AenBleidd
Copy link
Member Author

@davidpanderson, I think check for new version after connect to client is not too often. It is the way many application do their checks for new version.

@JuhaSointusalo
Copy link
Contributor

I haven't tried this yet but reading through the changes I don't think this works quite as intended.

When user clicks the Check new version menu item the chain of calls goes through handle_get_newer_version() and ends up in GET_CURRENT_VERSION_OP::do_rpc() . Contrary to its name, do_rpc() doesn't actually do the RPC, it just queues it and returns. handle_get_newer_version() then doesn't wait for the version download to complete and returns the result of previous check.

In other words, user can be told that there is no new version and a couple of seconds later a notice pops up saying there is a new version. Bad.

The client may be busy with some other RPC, or BOINC server may be super slow, or the user's network could be down. So the version check may take a long time to complete. You can't block the client or GUI while waiting for reply so you'll need to make the operation asynchronous by adding a new GUI RPC command to poll the status of the version check, similar to, e.g., get_project_config / get_project_config_poll . A Please wait message box would be nice so that the user knows that stuff is happening.

By default the client limits simultaneous file transfers to 8. I don't know if downloading the version info is included but if it is you need to add some mechanism that overrides the limit when the user requested the version check. If the client is in the middle of downloading a new app version it can take hours before the transfer queue is empty.

The client has daily schedules and usage limits to control file transfers. The version info is not much to download but if it isn't too hard to implement I'd like for the automatic version check to obey the network preferences. This is mostly on the grounds that if the client is told to (not) do something then it should (not) do it.

return;

if (!version.empty() && !url.empty()) {
message.Printf("%s: %s", _("A new version of BOINC is available for downloading here"), url);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't that be the branded app name?

@AenBleidd
Copy link
Member Author

@JuhaSointusalo, thank you for your detailed review. I've tried to do minimum changes because of the compatibility with old clients. It was my main motivation, I have plans to continue my work on this case and implement it more accurate. I'll try to take into consideration all your suggestions and make version check more flexible and more stable.

@ChristianBeer
Copy link
Member

I think we also need to review the wording of messages. Some of them don't feel like proper English to me. As I'm also not a native English speaker I would like someone else to take a look at it.

@AenBleidd AenBleidd restored the ClientVersionCheck branch February 23, 2017 12:05
@AenBleidd AenBleidd deleted the ClientVersionCheck branch February 23, 2017 12:12
@AenBleidd AenBleidd restored the ClientVersionCheck branch February 23, 2017 12:13
@AenBleidd AenBleidd deleted the ClientVersionCheck branch February 23, 2017 12:19
@CharlieFenton
Copy link
Contributor

There is another issue with the version check. If a user has downloaded a "branded" (skinned) version of BOINC from World Community Grid, GridRepublic, etc., should BOINC be checking their web site for a new version with the same branding rather than Berkeley? If so, then it should also point them to that web site to download a new version. I believe that this is true of the existing version check in the Client as well as the manager's new version check.

@AenBleidd
Copy link
Member Author

AenBleidd commented Aug 18, 2017 via email

@CharlieFenton
Copy link
Contributor

CharlieFenton commented Aug 19, 2017 via email

@AenBleidd
Copy link
Member Author

AenBleidd commented Aug 19, 2017 via email

@CharlieFenton
Copy link
Contributor

CharlieFenton commented Aug 19, 2017 via email

@davidpanderson
Copy link
Contributor

Do we want to continue supporting branded versions?

@CharlieFenton
Copy link
Contributor

CharlieFenton commented Aug 19, 2017 via email

@TheAspens
Copy link
Member

TheAspens commented Aug 24, 2017

We (WCG) do want to continue our branded version. Our branding in the past of consisted of the following:

  1. Customized windows installer for things such as text shown during installation, the splash logo, inclusion of the project_init.xml to initiate attach to WCG, inclusion of cc_config.xml with a few different default options and the application in windows is seen as World Community Grid rather than BOINC.
  2. Skin customization
  3. Custom compiled binaries so that the icons displayed in windows render our logo. Also, there is one extra panel during the "Attach to Project" that explains the difference between a BOINC project (http://boinc.berkeley.edu/projects.php) and a WCG Project (https://www.worldcommunitygrid.org/research/viewAllProjects.do).

I have about 3-4 weeks of work of things to do and then I will be working on adopting a new version of the client (to go from 7.2 -> 7.10). We will having one of the IBM teams do the security review and then going through our client release testing (so we hope to align with BOINC 7.10 release timeframe although we tend to be slower).

We are trying to figure out how to simplify the branded configuration vs the standard BOINC client. What aspects of custom branding are you wanting to remove?

@TheAspens
Copy link
Member

I cannot find any place in the code where client_version_check_url in the cc_config.xml file is set to the branded version's web site, such as GridRepublic or World Community Grid. So it appears to me that the version check will always be checking for a new version of unbranded BOINC from boinc.berkeley.edu, even when the menu item says "Check for new GridRepublic version". In fact, I don't see any item in the branded skin.xml files with a URL for checking the current version, and the only place in the code which uses the organization_website is in the About dialog.

WCG includes a version of the cc_config.xml in our customized installer which sets this value. I'm attaching what is in our 7.2 client below

<?xml version="1.0"?>
<cc_config>
    <log_flags></log_flags>
    <options>
        <client_download_url>http://www.worldcommunitygrid.org/reg/ms/viewDownloadAgain.do</client_download_url>
        <client_version_check_url>http://www.worldcommunitygrid.org/download_all.php?xml=1</client_version_check_url>
        <network_test_url>http://www.ibm.com</network_test_url>
    </options>
</cc_config>

@mblumberg
Copy link

mblumberg commented Aug 24, 2017

Branded clients are mission-critical for us (GidRepublic, Charity Engine, Progress Thru Processors).

This functionality makes it possible to maintain a consistent user experience -- e.g. when a user sees an ad, comes to a website, downloads and runs an installer, etc, he or she gets constantly assured they are still in the same ecosystem, that the app they are installing is the one they meant to install, etc.

If any work is needed to update or maintain these features, we'd be glad to contribute. (Kevin, if you want to chat about this, let me know.)

@CharlieFenton
Copy link
Contributor

CharlieFenton commented Aug 24, 2017 via email

@mblumberg
Copy link

Thanks, Charlie. Do you mean {1} GR specifically faces a lot of work generating the new graphics and xml required by the new format, because our custom files are out of date? Or {2} Generally speaking, there's significant [technical] work remaining to get the Mac installer to the place where a skin could be added by anyone? (Ie the mac version of the installer doesn't effectively support skins at this time?)

@CharlieFenton
Copy link
Contributor

CharlieFenton commented Aug 25, 2017 via email

@mblumberg
Copy link

Charlie, is there any up-to-date documentation of the process of building Mac installers? -- E.g. something like the BOINC Wiki article Building a Windows installer for the BOINC client?

@CharlieFenton
Copy link
Contributor

There is a slightly out of date version of the build instructions at http://boinc.berkeley.edu/trac/wiki/MacBuild which I will try to update soon. The latest version of this document (corresponding to any particular version of BOINC) can be found in the source tree at mac_build/HowToBuildBOINC_XCode.rtf. You can access the source code tree by following the instructions at http://boinc.berkeley.edu/trac/wiki/SourceCodeGit.

Please note that the issue is not with these instructions. Building a branded version will require making a special version of the script mac_installer/release_boinc.sh for each brand (GridRepublic, Charity Engine, ProgressThruProcesors). The very old and obsolete special scripts are still at mac_installer/make_GridRepublic.sh, mac_installer/make_CharityEngine.sh and mac_installer/make_ProgThruProc.sh. Significant changes to these 3 scripts are needed. For example, they use PackageMaker, which has not been available for 5 years or so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants