the /view companion
all the urls of the cosmo site are of the form http://www.cosmo-model.org/somePath, but for the last 3 years, these urls are also valid: http://www.cosmo-model.org/view/somePath
these urls, shadow every directory in the site and provide a directory tree view if "somePath" is a directory or a simplified view if "somePath" is a file, with a fast way to see the parent dirview
this presents the need for these views, some technicalities and the way users adopted them (beyond initial intent, and some of their errors doing so)
yesterday needs
in its current form, the "view/" urls appeared after WG5 asked for a way to exchange random data files, initialy for exchange and offline verification, then for active processing (RFdbk).
ftp and scp were impossible (due to the HNMS limitations), but http upload was already in place (using the cmdline wget program). So the mechanism for uploading was there, and once uploaded, file urls would have to be distributed by mail!
this mouth-to-ear method seems too crude in the era of graphical access; so the /view urls were created, to easily navigate the folders and download their content.
In time graphical upload and file removal was glued on.
the WG5 folder today and the base repository folder
yesteryear needs
this is not the 1st time the "/view" urls are used in cosmo's site. Several years ago there was a need to inter-compare centres forecast, to locate discrepancies that shouldn't exist. For some years each service would sent MSLP and preci grib fields to MeteoSwiss, that produced charts and uploaded them to (a past version of) "view/" for all of us to see.
other than cosmo site, the srnwp-exchange site adopted the same way to distribute observation files to its subscribers some years before.
the map-exchange pages and the srnwp obs exchange page
and today
other than the initial WG5 datafile sharing, many others use the auto-generated directory views to upload share or delete files; there are folders with presentation files of every meeting (GM included) and most of them never end up with links in a "regular" web page; their remain visible only via a "/view" link
the upload plugin (or rather its server-side part), initially developed to send files after visually pressing buttons in the /view pages, also expanded it's use. Gradually it replaced all other uploading mechanisms (e.g. at its latest use, the GM registration personal details were handled by it)
the STC meetings presentations /view's upload plugin used elsewhere
origins
at my section we needed a way to display internally at HNMS the local model output, automatically (i.e. without writing new web pages for every run). At that time HNMS' graphics department was producing only paper charts and HNMS itself hardly had a site, but even today there is always some customized product that finds its place there that graphics department cannot generate.
the code of that internal site is copied to the cosmo site; the two usages are in general separate (chart-quick-view at HNMS, folder content at cosmo), but the code is exactly the same
more complex view: svg and (not plain) html comparing views: Cosmo vs HNMS sectB
programming
the "/view" pages are auto-generated by a server-side program that through the years has been written and rewritten in most technologies available:
- It's 1st form was as java servlets
(needed a java web-aware process (the "tomcat" server) that used user add-on java programs (the "servelts") to produce html text) - Most of the years it was a fastCGI program, written in c++
(a never ending process that the web service process contacts when needed, using a special format of data and control packaging (the fastCGI protocol)) - Today's version is a "reverse proxy" (also written in c++) (a never ending process that understand the web-native http protocol, that the frontend web-server redirects to without touching the original traffic (i.e. no extra transfer protocol, or filtering, or reformat (as fastCGI) is needed
two plugins were developed and are used by the /view program, one for uploading and one for file ops (mkdir and rm). These add ons are dual-coded (all versions in c++):
- reverse proxies when using the buttons in the /view pages
- plain CGI when used with cmdline wget
(CGI is a usual terminal program, that the frontend web server process starts when asked for and whose stdout is returned to the browser to display)
some code stats
the use ...
it isn't only WG5 that needed to share files, but also page maintainers (like WG coordinators and PP leaders) that had to upload files (documentation, meeting presentations etc). So the "/view" urls don't work only for some "parallel" directory (in out case the /view/repository) but also for the main site's directory tree (the /view/content).
The permission system treats the /view/repository and /view/content differently ((most of)repository is visible by plain users, uploadable by admins, /view/content only by admins) and this causes some misunderstanding (more on it next)
There are also folders for containing presentations from every STC or SMC meeting and some WG or PP presentations
... and misuse!
conceptually most /view/repository folders shouldn't be there; at some time they should migrate to the main site directory tree and have some tabular web pages with links to the files in these folders (like the GM presentation indexes). Not doing that, has 3 disadvantages:
- permission system: links in regular pages are available to any visitor. Most /view/something links have a permission restriction (for most, at least the plain "cosmo" user password is needed
- display problems: /view can show files other than directory listing; but these files are shown in a simplified form (i.e. Cosmo's html files are set up not to load menus if they are displayed within a higher level frame
- backup system: the repository folders are NOT backed up: still most of their volume are transient verification files that are useful for very short periods
the untidy and permission-denied view/ of GM2021 plenary GM2021 via a hand-written html page
or the sole use?
at my department, we never needed hand written html pages to present model products; the autogenerated /view-like pages are enough. Could this be true for the future cosmo site? most of its content has become irrelevant due to cosmo-to-icon switch. If the content diminishes enough, the /view shadow site could become the only one; i.e. just use a more visually-glorified ftp browsing mode to share everything!
Internal HNMS sectB "view/-only" pages
