-
Notifications
You must be signed in to change notification settings - Fork 462
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
Conversation
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.
…ion'. Fixed XML new version responce parse.
Fixed issue #1767 . |
@davidpanderson, @ChristianBeer, Could you please review this? Thanks |
It would be very nice an automatic update option as well which works like Windows Update. Download the update automatically and install it silently. |
@adamradocz, it is very dangerous to update app automatically. You can read more conversation here: #28 |
Not sure we want version check that often but OK. |
@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. |
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 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); |
There was a problem hiding this comment.
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?
@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. |
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. |
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. |
@CharlieFenton, client uses link from xml so it will be default link for
'vanilla' BOINC and another for each 'branded' version.
Best regards,
Vitalii Koshura
2017-08-18 15:12 GMT+03:00 CharlieFenton <[email protected]>:
… 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.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1768 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADFZob4T1c0c9nbisQ_K7J3j9sgD6C7kks5sZX-QgaJpZM4LtEbg>
.
|
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.
Can you or @davidpanderson explain to me how a version check is sent to GridRepublic, World Community Grid, etc.?
If I understand correctly, this is further complicated because WCG provides a branded BOINC installer for MS Windows but not for Macintosh, so they have Mac users download from boinc.berkeley.edu but Windows users download from WCG.
|
@CharlieFenton, I'm not sure that client_version_check_url should be
configured for branded version by the code. I think this option should be
configured by the installer. But this is my opinion only.
Thanks
Best regards,
Vitalii Koshura
2017-08-19 3:21 GMT+03:00 CharlieFenton <[email protected]>:
… 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.
Can you or @davidpanderson explain to me how a version check is sent to
GridRepublic, World Community Grid, etc.?
If I understand correctly, this is further complicated because WCG
provides a branded BOINC installer for MS Windows but not for Macintosh, so
they have Mac users download from boinc.berkeley.edu but Windows users
download from WCG.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1768 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADFZoWWU63LbJ3UnPEWUo1y1rraJRiq0ks5sZip5gaJpZM4LtEbg>
.
|
Again, I am not certain, but I believe that, except for the names of the installer and Manager, all of the brand-specific customization is provided by the skin.xml file.
|
Do we want to continue supporting branded versions? |
I too have wondered whether we should continue supporting branded versions. I suppose we should check with folks at GridRepublic and WCG. I think those are the only two still active, though I'm not sure about the status of CharityEngine or ProgressThruProcessors.
|
We (WCG) do want to continue our branded version. Our branding in the past of consisted of the following:
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? |
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
|
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.) |
Although the Mac Manager and screen saver still fully support branding, the Mac installer has gone through extensive changes since the last GridRepublic version (which was a very long time ago as far as I know.) The current Mac installer needs significant work to allow for branding of recent versions of BOINC.
|
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?) |
Neither #1 nor #2. The scripts to generate the custom Mac installer for all branded builds are very much out of date and it will take significant work to create new scripts to generate branded installers for the Mac. Adding the skins is the easy part. The way the installer is built has changed considerably since the 7.0 series due, largely because of changes made by Apple to their development tools.
And anyone can add skins to their copy of the Mac BOINC Manager after it is installed.
|
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? |
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. |
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.