Question: Can the client view file versions be correlated to client version enforcement in the admin utility (Similar to restricting mgmt snapin versions in C1) ? This only applies if updated views cannot be used by older clients. To clarify...In large distributed environments it is not unusual for client versioning to have different authoritative standards. For example, when we were running GW 8, the clinical technical management would not let their clients update from their v6.5 clients. This would have likely carried through to the 2012 version as well.
In the past the view files have been backward compatible (check me here). I simply wanted to ensure this legacy binary trail was removed or addressed (the only reason version matching/enforcement was suggested).
AnswerThe client will be enhanced to either a) always prefer local copies or even better b) remove the utilization of view files altogether.
Question If HTTP is used by the POA to update client software should a new discreet port be used? In large environments I do have some concern about normal POA CS activity and client update contention on the same port. If WAN links stand between the update target and the POA, native internet latency could further aggravate contention issues. Additionally if the admin was to decide to prohibit client updates over WAN links this could be accomplished at the firewall/security layer, if a different port was used, and allow extra-net clients to fall back to the configured URL for client updates. All while allowing normal POA CS traffic to cross those links normally with no concern for contention issues (even if just perceived).
I think if ports can be added for pop, imap and soap one can be added for auto-update if it results in a more flexible environment. I think these are some of the simple and operationally valuable things administrators are looking for.
Answer:Regarding HTTP... That part of the update process is still in flux. We have considered several mechanisms some of which may alleviate the concerns for running on a discreet port:
1). Use the existing client/server mechanism to transfer files. This would not run over HTTP at all but may place additional strain on the POA.
2). Expose the files via the POA's HTTP interface... we already do this for a number of files. In fact WebAccess downloads file attachments through this sort of a mechanism. It runs over the HTTP port already specified in admin.
3). Use the jetty instance to host the setup files... Paul has modified the install to automatically configure the admin jetty service to host the setup files. In this case the default URL would actually not run through the post office at all.
4). We've always planned for the ability to set a separate download URL for the client setup files in the Admin Console. This would allow the administrator to host the files anywhere (i.e. on a separate instance of Apache running somewhere) and point all of the update traffic to it. In this case the POA's HTTP would be bypassed altogether. We were reluctant to include this as the only option because we wanted something that would work "out of the box"