This section of the developer documentation steps through the various component parts that make up Titan. Notes are provided to discuss the "why's" and general principals, and where appropriate, typical maintenance tasks.
An assumption will be made throughout this section that the reader is a well-versed Titan user as well as Titan developer. That is, there is no Titan task you have not accomplished. You’ve been in every tab of every module and you know what happens there. Likewise, that you’ve done a few Titan installs and understand the basic structure of the deployed executables.
General Thoughts
Titan is a product. Even though it isn't shipped as shrink-wrapped software, it is still treated as a product.
All Customers, Not Just the Latest
Titan needs to be designed for all customers, not just the current big customer. Even the little customers deserve to have their needs addressed. It is tempting to add software into Base to make the current big contract easier. However, it is wrong if the feature is only for one customer, particularly if the cost of adding that feature makes even one small task or operation for other customers more difficult.
Security Comes First
Titan ships with a page-level security. Customers expect Titan to be secure. Throughout development we strove to prevent any security leaks. That isn’t to say that they aren’t there, but if we saw or even if we thought we saw a security issue, the feature was not added. This is serving our customers who trust us to do the right thing. Note that the workstation allows the submission of XML and should always be run under https as should any displays that submit passwords.
Code Quality/Code Simplicity/Code Consistency
Product requires quality code. A bug in one-shot software affects one customer; a bug in product affects every customer. Quality is an assumption.
Likewise, product has to be maintained for years. It can be tempting to add some fancy twists every now and then or to want to use the latest and greatest nifty tool. However, the first rule of maintenance coding is consistency - make the code you add look like what it is there. In the end, you are better served when you return to the code years later.
Minimize use of 3rd Party Libraries
An overriding philosophy of Titan is to minimize reliance on 3rd party libraries. Titan Base uses two 3rd party libraries: CK Editor and Telerik (tree only). We have paid for redistributable licenses for both packages.
That said, before a 3rd party library is incorporated its use is scrutinized. Multiple studies show that COTS (Commercial Off-the-Shelf) software is more likely to cost more in development and maintenance in the long-term than it will save. Thus, first and foremost, a 3rd party package must solve a problem for Titan that does not have a solution that can be implemented in a few weeks. The CK Editor is a good example of this; the Telerik tree is probably not. We could have developed a tree in a few weeks.
Second, before a 3rd party library is incorporated, the cost has to be addressed. If there isn’t a redistributable license, every release will incur the cost of additional paperwork tracking the software cost. For dtSearch, a 3rd party library external to Titan Base, this is an acceptable cost as it is the best solution for our customers.
It should go without saying, but…..just because a library is open source, or just because a library is available on the internet, or just because a library has no cost for single applications, the library may require a fee if deployed in a product. It is necessary to read the fine print of the release notes.