chtserverinventory.gif


CHT SERVER OVERVIEW -- UNDERSTANDING CHT SERVER TYPES


The purpose of this document is to enumerate the various CHT Server examples in our tool kit. There are presently 16 example CHT Servers.

These sixteen examples consist of three out of four of the different types of CHT Servers. Discussed in this document, are CHT servers of Type 1, Type 3 and Type 4. There is presently no Type 2 server, only an expanding specification for a Type 2 server under active development during the course of 2015.

The next image of a template interface from the CHT BrowserServerInitializationControls Template illustrates the presenly active server type choices and the future location of our Type 2 option.

 

chtservertypes.png

 


 

Type 1 - CHT "Browser" Data Server

There are five "Browser" server examples provided with your CHT Toolkit installation.

browserserverstype1.png

 

As the terms browser and data in the above title imply, the client-side "application" contacting and communicating with a Browser Server, is not a Clarion application, but a web browser. Or, a web browser embedded into a Clarion application window as is the case with CHT's Support Forum Client, HNDBRWCL.APP, the server for which is HNDMTSNG.APP.

While all server-based data applications imply a two-piece design, consisting of a server part and a client part, the CHT Type 1 designation denotes a Browser-based client and a Clarion-based server.

So, "Web Applications" communicating and interacting with Type 1 servers, consist of "Scripts" that are made up of a combination of HTML 5, Javascript, and Cascading Style Sheets (CSS). These scripts, running as code, render the user interface inside the web browser, acting as the code interpreter. Scripts draw the buttons, list boxes, menus and a host of other control surfaces that the user interacts with to view, add, change, delete, report and process data records stored in the server's data files.

A Type 1 Server is a data server capable of serving across the web, across the WAN, or the local network, from any data base type, ISAM or SQL, for which Clarion has file drivers. If you still prefer Topspeed format, or you're using MySQL or PostgreSQL or Microsoft SQL Server, you can build solid, fast data servers capable of communicating with a wide variety of modern browsers based on computers, tablets or smart phones, with this CHT technology.

 


 

Type 2 - CHT "Universal" SQLite Data Server (Under Development)

CHT has templates and classes for an SQLite-based "Universal" server in design/development.
 
In late 2014, we wrote a paper discussing and evaluating the use of the SQLite driver with Clarion. That paper can be found here. While SQLite is a powerful and portable SQL data format, it has no remote client server capabilities.
 
Our analysis at that time led to the decision that our Type 2 server could become at least a dedicated SQLite client server, accessorized with templates and classes with which to build powerful data servers and clients that can be used from anywhere across the internet, the WAN or locally on a business network.

 
As we design Type 2, we will endeavour to work well beyond "at least" and obtain the design goal of universal accessibility, yet still maintain our already state-of-the-art data security, encryption and compression aspects.
 
While our Type 1 servers support primarily browser-based clients, and our Type 3 servers support primarily clarion-based clients, ideally a Type 2 server should be made interactive to both browser clients and Clarion clients, and for that matter, even to C#-based, and other-dev-language-native clients running on PCs, tablets and smart-phones.
 
CHT has had its own built-in-house, thoroughly proven, data packaging and web/network transport methods evolving for a dozen or more years now. You can read more about those things in the sections in this paper dedicated to discussing the specifics of Type 1 and Type 3 servers. Up to the present time, Clarion has provided very little, actually or notionally, to cause us to want to look at native Clarion componentry for viable functionality to support our server design choices.
 
With the advent of C10 and the incorporation of JSON data packaging, Clarion code-based socket classes and some apparently viable (though still to be extensively viability-tested) HTTP transport methods, we will consider incorporating some of this new Clarion-native capability into our Type 2 server/client designs. But only if it proves to be up to the very high standards that we've already set over the last fifteen years of CHT-in-house web server design.
 

 


 

Type 3 - CHT "Client" Data Server Examples

There are five "Client" data server example applications provided with your CHT Toolkit installation.

 

clientservertype3.png

As the terms client and data in the above title imply, the client-side "application" contacting and communicating with such a server, is a Clarion application. While all server-based data applications suggest a two-piece operation, consisting of a server part and a client part, the CHT Type 3 designation denotes both a Clarion-based client application and a Clarion-based server application.

A Type 3 Server is a data server capable of serving across the web, across the WAN, or the local network, from any data base type, ISAM or SQL, for which Clarion has file drivers. So if you like SQLite or still prefer Topspeed format, or you're using MySQL or SQLite or Microsoft SQL Server, you can build solid, fast data servers and clients, which include encryption and data compression, with this CHT technology.

We keep at least one of these servers (.TPS based) on-line full time to serve as an example. It serves up Clarion's "People" file and can be accessed using demo client application hndclientCLlean4view.app by pointing it at http://www.cwhandy.ca:8080. Please look up a user name and password in the data file which accompanies the server in your /hndapps/ directory.

The server application under which this user data file is located, is named hndclientSVlean4view.app.

 


 

Type 3 - CHT Authenticating "File" Server Examples

There are four authenticating "File" server examples in the CHT Toolkit.

fileservertyp3.png

 

These servers are completed by a variety of Clarion-based remote file-client applications. Type 3 file servers authenticate the connecting user. That is, they ask connecting users to identify themselves with a three-piece login (i.e. Last Name, Email Address and Login ID) or two-piece login (i.e. User Name, Login ID).

CHT's WebUpdater installer validates CHT user download privileges against this style of CHT server using a three piece login. WebUpdater has been providing CHT installations all the way back to Clarion 6.3. Before that, its predecessor, called WebLoader, was also an early example of one of these authenticating file servers using the Type 3 modality.

 


 

Type 4 CHT "Static Page" Web Server Examples

There are two "Static Page" web server examples provided in the CHT Toolkit. "Static Page" web servers are basic file servers -- since a set of static pages is what generally constitutes a "website".

 

staticpageservertype1.png

A Type 4 CHT Server, does not require user identification before permitting a connection to it. This server type, as a rule, serves up most file types and web pages to anyone who connects to it.

That doesn't mean they "have" to serve up all file types, or service all browsers or application clients. Higher or lower levels of access control can be added either by inserting "plug-in" templates like "CHT ServerFileHandlingOverrides" or by embedding into server functions that control user access via client-type identification or file-type identification.

One of these example applications, originally built with CHT Templates for Clarion 5.5, called HNDSLFSV.APP, has been serving up CHT's main website for more than fifteen years.

 


CHT SERVER INVENTORY -- TYPE 1 CHT SERVERS


TYPE 1 -- CHT "BROWSER" SERVER EXAMPLES AND RESOURCES

There are five "Browser" server examples complete with client-side interface scripts, accompanying three of the examples. Server examples are described in their splash screens as follows:

Servers:
HNDMTSNG.APP| HNDEVENTSERVER.APP| HNDDNLSV.APP| HNDLRNSV.APP| HNDINSTALLATIONSERVER.APP

 

CHT Forum Server HNDMTSNG.APP

The most expansive and day-to-day useful example, HNDMTSNG.APP, is one we've been using as our product support forum for more than twelve years. This browser-based web application has served the CHT developer community as its primary point of contact for questions and answers about Clarion application development with the CHT Toolkit since October 16th, 2002.

That's when Russ Eggen asked the very first question ever posted on what was then our newest and latest web server technology. Here is a snapshot taken recently, of a thread based on Russ' question.

To answer your question, Russ, yes this is strictly "web" based. This server's "scripts", are a combination of HTML, JAVASCRIPT and CSS, which provide a browser-based interface to the data from remote server data files. The scripts run equally well in any modern web browser as well as on tablets from all known sources. While, for practical reasons, we've not formatted the forum browse to fit onto smaller smart phones, the scripts will run and display our forum even on these devices when tipped into an horizontal orientation.

User "queries" into the data files provide the basis for a "browse". Individual records displayed in the browse can be viewed in a "preview" form and new records may be added in an "editor" form. Users may then edit/change/delete their own records. There are even PDF-based reports available.

Browse data bundles are packaged in what we've coined JDO Objects, for Javascript Data Objects. Data travels along with smart, self-validity-checking Javascript code, based directly on validity checks in the Clarion data dictionary, assuming such validity checks are provided there.

The server is 100% Clarion + CHT templates and classes, and was originally built with Clarion 5.5. The server is presently built with Clarion 9.1 and when Clarion 10 is out of beta, we'll use that. It contains some embed code, as does any sophisticated Clarion data application, but most of the code is template-generated by ABC and CHT templates.

chtforumserver.png

Since it's inception, we have never removed any records from this server's data files, so recently, we posted the following query to the server, based on our vague memory of when it first began live operation.

Here is the query that raised the information shown above. This server's data file, which is .TPS-driver-based, contains nearly 70,000 records and it responded with the information that you see displayed in the browse, in under 5 seconds.

chtforumserverquery.png

MORE TYPE 1 SERVER INVENTORY INFORMATION COMING HERE...

 


TYPE 3 -- CHT "AUTHENTICATING" FILE SERVER EXAMPLES AND RESOURCES


There are four "Authenticating" file server examples and five "Authenticating" file client examples. These nine examples are described in their splash screens as follows:

Servers:
HNDFILSV.APP | HNDFILSVSPECIAL.APP | HNDFILESERVERLEAN.APP | HNDSVLV.APP

Clients:
HNDFILCL.APP | HNDFLCLN.APP | HNDFILECLIENTLEAN.APP | HNDLIVUP.APP | HNDINSTALLMYFILES.APP

 

fileserversandclients.png

The clients are able to authenticate themselves against the servers because type 3 servers use a customer, user or members file containing login information that is unique to each customer/user/member. Before being able to log in and receive files, the logee must be able to configure their individual client application with either a three-piece login or a two piece login.

Which type of login is required is built into the server by the developer, using changeable settings on the CHT template interface. Our demo servers and clients include examples of both login types.

Each of the servers comes ready for testing in your /hndapps/ directory. These server and client examples do not come pre-compiled, but the source is complete and ready to compile and run. The servers come with minimal data files in .TPS format so that, using any server's designated client(s) you should be able to run an upload/download test locally or across your network or across the internet. Either use an existing account in the server's user file or create a new one. Either option will work.

Server subdirectory convention, unless changed or re-configured by you, is to open from the hndapps directory, assuming you start them there, looking for its data files in the directory with the same name as the server, with its /run/ directory one below that and with its /files/ directory one below that. If you compile, run and test, the server from a different location then it's up to you to supply it with the correct data and download files located in the correct locations, obviously.


Server Example: HNDFILSV.APP

Server HNDFILSV.APP looks for its (.TPS) data files in /hndfilsv/ below the /hndapps/ directory from where you are test running it.

The *cfg.tps file is the server configuration file.

The *mem.tps file is the server member or user file.

The *memext.tps file is file joined to the member file containing extended member/user information. The structure of this joined file is fully under the control of the developer. That being the case, an existing customer/member/user file with a structure that does not meet the server's field requirements for server login, can be readily joined here with the developer setting the file design parameters for the "memext" file in the server dictionary.

The *qry.tps file contains prebuilt queries for the members maintenance browse built into the server.

filsv_datafiles.png

Server HNDFILSV.APP is a server design that lets you configure a download/upload directories list and a download files list, dynamically from the server menus. The files are located by the server in the /run/ directory. No files above the /run/ directory are visible to the web and no files above the /run/ directory are invisible (theoretically) to the web.

The server's splash screen reads as follows:

This application is intended as a starting point for developers to build file transfer servers of various sorts that act like FTP servers but utilize the HTTP protocol including encryption and compression.
 
Several demo client applications are provided to subscribers: HNDFLCLN.APP, HNDLIVUP.APP and HNDFILCL.APP. Another client application called HNDHTGT.APP illustrates making on-the-fly file requests from this server using the HNDHTTP and HNDHTTPClient classes.
 
The server maintains complete control of which files and directories are visible to the client. File transfers are optionally compressed and/or encrypted at the request of the client application.
 
This application is entirely template-built and contains almost no hand-embedded code.
 
NOTE: This is a starting-point server from which to build forward. The "file transfer" portion of the server is already installed.
 

The servers "directory" files are simple .TXT files called HNDFILSVDIRS.TXT and HNDFILSVFILES.TXT, (named after the server) with 'DIRS.TXT' and 'FILES.TXT' appended. They contain, respectively, a list of directories visible to the client and a list of files visible to the client. Once created from the server's menus, these text files may be edited, server-side, in order to add or remove specific files or directories, so as to make them visible or invisible to the client.

Only files actually mentioned in the the HNDFILSVFILES.TXT list may be downloaded and only directories mentioned in the HNDFILSVDIRS.TXT list may be downloaded from and uploaded to.


filsv_dirfiles.png

Server HNDFILSV.APP comes with three sample download files already configured in the HNDFILSVFILES.TXT list. These are CHT PDFs located in the /files/ directory. You can add more files here for testing or add more subdirectories containing files.

After making any additions of files or directories run the appropriate server menus "Refresh Server Directories" first and "Refresh Server Files" second. And don't forget to unlock these directory files from the server menus. Keeping them locked makes the directories and files lists separately invisible to the client. You might want to "lock" these lists, for example, while you're in the process of creating a new files list, after a product update.

We also suggest that when interacting with the server interface, always check the "Busy" switch first. That allows the client to detect that something is happening on the server-side that it should avoid. Most clients have been taught to recognize this busy setting and will warn the client side user to try again later.


filsv_downloadfiles.png

You should be aware before you start adding files for testing, that CHT servers can be made to accept or reject certain file types at the discretion of the developer.

There's a template called ServerFileHandlingOverrides applied on the main server procedure which handles all kinds of possibilities concerning what or what should not be downloadable, uploadable, visible or invisible to the client. If you're building an installation server, for instance, you may want to allow only certain file name and extensions.


serverfilehandlingoverrides.png

Here is an example embed we've added to the the server function GetPutFileApproval(). The server checks here first (seeks prior approval) before allowing a file, sent to it by the client, to be placed into one of the server directories. We have a couple of CHT equates in this embed, which contain a list of file extensions that are legal to upload to this server. To change the rules, change the equates or remove them and add your own.


getputfileapproval.png

Video About: HNDFILSV.APP

There's a pretty good video about this specific server and its client illustrating a number of things that you might be interested in knowing about it. CHT Secure HTTP File Server Wizard (19 Minutes)

 


Server Example: HNDFILSVSPECIAL.APP

Server HNDFILSVSPECIAL.APP looks for its (.TPS) data files in /hndfilsvspecial/ below the /hndapps/ directory from where you are test running it.

The *cfg.tps file is the server configuration file.

The *mem.tps file is the server member or user file.

The *memext.tps file is file joined to the member file containing extended member/user information. The structure of this joined file is fully under the control of the developer. That being the case, an existing customer/member/user file with a structure that does not meet the server's field requirements for server login, can be readily joined here with the developer setting the file design parameters for the "memext" file in the server dictionary.

The *qry.tps file contains prebuilt queries for the members maintenance browse built into the server.

filsvspec_datafiles.png

Server HNDFILSVSPECIAL.APP is a server design that lets you configure a download/upload directories list and a download files list, dynamically from the server menus. The files are located by the server in the /run/ directory. No files above the /run/ directory are visible to the web and no files above the /run/ directory are invisible (theoretically) to the web.

The server's splash screen reads as follows:

This application demonstrates primarily, the use of two Clarion Handy Tools Templates called EmbedBrowserServer and BrowserServerInitializationControls. This application uses a dictionary called HNDFILSV.DCT.
 
These extension/control templates provide TCP/IP connectivity with a browser or client application. In this particular example, application functionality has been limited to acting as an HTTP file transfer server. It requires a file transfer client to interact with it. This "special" version of the HNDFILSV.APP server is dedicated to working with CHT demo app HNDINSTALLMYFILES.APP, which is a basic file client aimed at getting you to across-the-web app installation.
 
The server maintains complete control of which files and directories are visible to the client. File transfers are optionally compressed and/or encrypted at the request of the client application. This application is entirely template-built and contains almost no hand-embedded code.
 

The server's "directory" files are simple .TXT files (named after the server) with 'DIRS.TXT' and 'FILES.TXT' appended. They contain, respectively, a list of directories visible to the client and a list of files visible to the client. Once created from the server's menus, these text files may be edited, server-side, in order to add or remove specific files or directories, so as to make them visible or invisible to the client.

Only files actually mentioned in the the HNDFILSVSPECIALFILES.TXT list may be downloaded and only directories mentioned in the HNDFILSVPECIALDIRS.TXT list may be downloaded from and uploaded to.


filsvspec_directoryfiles.png

Server HNDFILSVSPECIAL.APP comes with three sample download files already configured in the HNDFILSVSPECIALFILES.TXT list. These are CHT PDFs located in the /files/ directory. You can add more files here for testing or add more subdirectories containing files.

After making any additions of files or directories run the appropriate server menus "Refresh Server Directories" first and "Refresh Server Files" second. And don't forget to unlock these directory files from the server menus. Keeping them locked makes the directories and files lists separately invisible to the client. You might want to "lock" these lists, for example, while you're in the process of creating a new files list, after a product update.

We also suggest that when interacting with the server interface, always check the "Busy" switch first. That allows the client to detect that something is happening on the server-side that it should avoid. Most clients have been taught to recognize this busy setting and will warn the client side user to try again later.


filsvec_downloadfiles.png

You should be aware before you start adding files for testing, that CHT servers can be made to accept or reject certain file types at the discretion of the developer.

There's a template called ServerFileHandlingOverrides applied on the main server procedure which handles all kinds of possibilities concerning what or what should not be downloadable, uploadable, visible or invisible to the client. If you're building an installation server, for instance, you may want to allow only certain file name and extensions.


filsvspec_fileoverrides.png

 

 

 

MORE TYPE 3 "AUTHENTICTING" FILE SERVER INVENTORY INFORMATION COMING HERE...

 

 


TYPE 3 -- CHT CLIENT DATA SERVER EXAMPLES AND RESOURCES


 

 

 


TYPE 4 -- CHT "STATIC PAGE" SERVER EXAMPLES AND RESOURCES


 

 

 

 

 

 

THIS PAPER UNDER ACTIVE DEVELOPMENT 2016


chtcopyrightgray.gif