Class: GeneralTransitionEngImpl

Returns true if the application override is configured to use alternate storage to the default storage provided here.

Replaces the functionality of store_data if alt_store returns true.

In the application version of this method, the point is to return data that can be written into a file using the method store_data.

The map _uploader_managers stores a chunk manager per transition token. Elsewhere in this documentation, the transition object and its token is explained. One kind of transition is one that takes in data from the client, and its token will last as long as the data is being uploaded.

The chunk manager has the purpose of return a collection of chunks in preparation for writing to storage. In some applications, the chunk_mover may return false if the chunks cannot be a complete file. The expectation is that the chunk mover will be called again after adding more chunks, until the data can be stored as a complete object.

When the storage operation has been performed, the store_data method will return an identifier that identifies the data. This may be a hash of the data. Ultimately, this identifier will be returned by this method.

This method is called by chunks_complete.

The post body must have the token field with the value being the transition token required by the request.

The previously prepared chunk manager will be accessed by mapping the token to the chunk manager in the _uploader_managers map.

The post body must have one of the following fields:

• file_list - an array of file descriptors
• file - a single descriptor

If the post body has the field file_list,which must be an array of file descriptors, then each descriptor will have at least one field name. The chunk manager will have a map, _chunkers, which maps the file name to the array of gathered chunks.

If the post body as a file field instead of a file_list field, the chunk manager will look for the one array where all the chunks being uploaded have been gathered for storage in just one file.

This method attempts to create a unique name for the file from the information that has been passed to it. Furthermore, it makes use of the transition class object's file_entry_id.

This method is often called by the application's session manager as a part of transition finalization.

Calls the node.js Buffer.concat method. Some application may do something else. Returns a buffer.

A number of parameters are provided for applications needing more complexity than this method provides.

As a default, this method calls node.js mv.

Initializes a chunk manager that will receive a number of files identified in the requet body of an uploader type of transition. The chunk manager will be keyed (remembered) by its transition token.

The post body should have a field file_list which must be an array of file descriptors. Each descriptor will have at least one field name. The chunk manager will have a map, _chunkers, which maps the file name to an empty array. The empty array will later be filled with chunk data.

If the post body does not have a file_list field, the chunk manager will keep just one array where all the chunks being uploaded will be placed for future storage in just one file.

This method is often called by the application's session manager as a part of transition processing.

This method returns false. It should be overridden in applications using crytpo key processing.

At this level, this method just sets the configuration and the database referenc.

This method sets back references to other lib component class instances. It also tends to the importation of crypto keys.

This method sets back references to the contractual methods which provide the skeletal outline for handling client requests. The contractual class methods, especially those for transition processing, are generally the callers of the application's transition engine. But, the transition engine may call back to those classes if needed (depends on the application).

Accepts a reference to the application supplied web socket server manager and sets the web_sockets field to it.

At times, the transition engine will use the web socket service to fire off messages to listening clients.

By default, this method calls the async writeFile method to store data. Some applications may need to route storage at this point.

This method is provided for those applications using persistent storage use meta descriptors of files.

This method takes in the client's POST request body (or endpoint message) and the list of files associated with it. In some applications, the files map may be part of the request body. In other applications, the files map may be associated with a session token or session and might be cached between calls to the upload_chunk.

The post body must have the token field with the value being the transition token required by the request.

The previously prepared chunk manager will be accessed by mapping the token to the chunk manager in the _uploader_managers map.

The files parameter must alwasy be a map even if there is only one file in files. If there is just one file, this method will check to see if uploading has been prepared to manage just one file. If it has been prepared to upload more, it is possible to have just one file if it is the last file still gathering chunks from the client. Complete files may have already been finalized. (This is why there are differen field names for the single and multiple case.)

This method is often called by the application's session manager as a part of secondary transition processing.

This method servers to upload a single file or multiple files in response one request, where all the files are complete upon arrival. (If chunking has occurred, it has been handled by standard HTTP mechanisms).

The function of this handler is fairly common code stacks. Other methods in the class are useful in situations where data undergoes intermediate treatment during data gathering or when data is coming in messages from the endpoint server. Usually, this method is used when uploading a file from disk and passing it through standard forms.

This method augments the placement of the file into an application directory by adding descriptors of the file into the DB (which is again defined by the application).