Over the last few years, we have seen a huge increase in the number of community development projects, shared extensions and a rise of third-party companies specialising in customization services for Kayako support desk software. From iPhone applications to big screen ticket monitoring modules, there are more third-party products and services available to supplement your Kayako support desk than ever before.

We frequently receive comments from developers who are extremely happy with SWIFT3, our own framework on which we have built our support desk solutions. They tell us that the simplicity of the code makes it very easy to extend their support desk – everything is intuitive and “where it should be”.

We’re very pleased with that. However, Version 4 (and the direction in which we are taking it) introduces new requirements and asks more of its underlying framework: such as complete and out-of-the-box support for Unicode and support for many database systems.

SWIFT3 is still entirely fit for purpose. We just intend to make SWIFT4 even better. As it turns out, we have gone much, much further than making SWIFT4 “better”, starting from the ground up. Read on to find out more.

This post is deliberately brief and non-technical, aimed at both devs and users. It has been written to give you a sense of the big changes that are to come in SWIFT4. If you’re hungry for more technical details, we’ll be making additional postings about SWIFT4 in the near future.

SWIFT4 framework

Everything about the underlying framework has changed. If we haven’t rewritten the code, then it has been refactored to follow a pure and consistent object oriented model, built around Models, Views and Controllers (MVC pattern). As SWIFT4 currently stands, only two source code files contain procedural code.

If you are familiar with development frameworks such as Code Igniter and the Zend Framework, you will be immediately familiar with SWIFT4. SWIFT4 provides you with methods, interfaces and the tools needed to rapidly extend and build upon the functionality of your support desk.

Modules

As with Version 3, the framework is built around modules, conceptually working in exactly the same way as they do in SWIFT3, but under the hood engineered very differently.

SWIFT4 for purpose and scalability

Rather than adopt an existing application framework we have chosen to develop our own.

SWIFT4 adds context of the support desk to development, making it easier for even beginner programmers to jump in and start building and extending. SWIFT4 only has one job to do, which is to power your support desk and any other applications you build on top of it. With just one job, we have been able to ensure that SWIFT4 is lightweight, without bloat and very easy to get your head around.

Dynamic instantiation of libraries ensures that the application is not bogged down with global includes. Code and data will only be loaded where it is needed: SWIFT4 enforces an on-demand dependency loading policy.

Security, reliability and rapid development

From the ground up, SWIFT4 has been built with reliability and security in mind. SWIFT4 provides developers with singular libraries, methods and sub-frameworks to make development a more rapid and manageable process.

For example, we have removed all global variables, except for a central global store which SWIFT3 developers will already be familiar with – $_SWIFT. The framework has been developed with support for code hooks for drop-in plugins, as well as drop-in modules.

In-line includes and imports will no longer be necessary and actively discouraged, as a central loader ($this->Load->Library(’Visitor:VisitorBan’);) handles the loading of libraries and imports them directly into the current namespace for ease of access ($this->).

Loose coupling (having fewer components rely on each other) contributes to the reliability of the overall application. From our perspective, testing and maintaining code becomes much easier. From your perspective, modifying code and extending functionality becomes easier, with less worry of unintentionally affecting functionality later down the line.

Native support for search engine and user friendly URLs, automated loading

SWIFT4 will no longer use query strings (www.acme.com/index.php?_a=this&b=that&c=something). Native support for clean URLs will make them search engine and user friendly, while also taking care of automated library loading (www.acme.com/Module/Controller/Action/…).

ADODB (with PDO support)

SWIFT4 will use ADODB – a fast and reliable database abstraction library for PHP. This means that SWIFT4 will support all of the database systems which have ADODB drivers, which includes support for MySQL, Oracle, MSSQL, PostgreSQL, Access and some ODBC interfaces. Full list of ADODB drivers.

ADODB also supports a pass-through to PDO (PHP Data Objects), which is PHP’s native data-access abstraction module. It works in very much the same way as ADODB does, and because it is natively executed, offers substantial performance gains. Full list of PDO drivers.

Unified search engine

One of the things we are most excited about in SWIFT4 is a new, unified search engine. To bring full Unicode support to our product despite database limitations, and the need to engineer a generic engine which will work across any system, we have built our own.

The unified search engine will cover all areas of the support desk (SWIFT4), and we will be building a single point of search feature which will allow you to perform a search over tickets, chats, contacts, and so on.

The search engine will introduce full Unicode character support – resolving the word stop and delimiter problems we have encountered with MySQL’s lacking handling of Unicode character sets (Japanese, Chinese and other ideographic languages).

A full n-gram engine, a lot like Google’s, has been implemented for fast, efficient partial phrase matching. An n-gram is a sub-sequence of tokens (words) generated from a sequence (a sentence). For example, “this sentence will have six words” has 21 potential n-grams:

• this
• this sentence
• this sentence will
• …
• sentence
• sentence will
• sentence will have
• …
• etc.

By default, the engine will generate up to 6-grams (three word sequences). This number of grams will be adjustable, allowing you to trade database size against flexibility in searching.

The search engine will support “exact phrase matching”, token/phrase exclusion (-exclude), and will intelligently handle symbols and punctuation. This means that you will be able to search for code (<?php echo “Test”; ?>) – something that even Google’s search engine cannot do in a meaningful way.

As well as the flexibility and powerful searching tools that the engine provides, one of the best parts of our new search engine is that it is fast. Really fast.

We will be posting about the search engine in a lot more detail in the following weeks to come.

Drop-in plugin support

SWIFT4 will support code hooks, enabling support for drop-in plugins and extensions. We aim to include as many hookable locations as possible, without impacting the clarity and simplicity of the core code. This means that we will be including hooks in places where hooks will have a conceivable use. However, we will always be open to new hook location requests, and will be urging developers to make suggestions during the public preview phases of Version 4.

By supporting drop-in plugins, customers will be able to add and build upon the functionality of their support desk by making no (or at the very most, few) code edits to the core files. Simply drop in your code files, and voilà.

• Sharing modifications and extensions will be simplified. Authors will no longer need to produce extensive and complicated lists of code modifications and hacks to core files.
• Support desk upgrades will be simplified. No longer will you need to port code modifications to new versions of the core files.
• Multiple extensions and modifications will be far less likely to interfere with each other.
• Leased license customers who have not purchased access to the source code of the core files will still be able to extend their support desk, just like owned license holders are able to.

APIs

You will be able to interact with your support desk’s data using an extensive XML (REST) API. We will also be thoroughly documenting SWIFT4’s internal API – detailing all of the interfaces, libraries and methods which you can use to build on and extend your support desk.

Open application protocols

Spurred by the fantastic response from the community following our recent publication of some Version 3 application protocols, we are committed to opening all of our application protocols with Version 4, including the operator’s desktop application, live chat code, SyncWorks, InstaAlert, KayakoMobile and protocols for our other products.

All of the protocols in V4 will be substantially different to those in V3; so much so that we predict essentially all current V3 applications will not work with V4.

This was a tough decision to make, and a necessary evil. While we did not want to create extra work for developers, we wanted to avoid holding V4 in the past by engineering vast amounts of legacy support into the application.

We have learned an awful lot during the lifetime of V3 and from our relationships with third-party developers. We wanted to apply what we have learned to make absolutely sure that V4’s application protocols are flexible, extendible and fit for the future, with a long shelf life. We will publish these protocols in good time so that developers can update their applications before V4 is launched.

We fully appreciate the need for openness and are aware of the limitless opportunity it opens up for our customers. We anticipate fantastic things from third-party developers and community projects, like IT2Be’s iPhone client, Craig Brass’ Blackberry client, and the Kayako sponsored open-source project pyLiveResponse (a multi-platform alternative to the operator’s desktop application).

Clean XHTML, API generated interfaces

All of the support desk interfaces are built with clean, simple and easy to modify XHTML and CSS.  We have built the support centre (user-facing support desk) with customization in mind – all of the code is self-explanatory, with intuitively named elements and classes.

We are confident that someone with even the smallest of experience with HTML will be able to make cosmetic modifications to their support desk.

Most of the interfaces will be API generated, using JavaScript. This removes huge amounts of code and server-side logic needed to construct the interfaces (for example, zebra striping of table rows and filling out tables is now done in the client). Raw HTML will no longer be found in any of the core controller code.

What is to come

We hope that you have found this post informative, and that you are as excited as we are about the new framework. We’ll be posting about SWIFT4 in much more detail – its libraries, modules, plugins, a walkthrough of the structure and “how we built it” articles. We’re working incredibly hard on Version 4, and although we are struggling to find time to write, we’ll certainly do our best to keep you informed.