Using Glasswall’s Core 2 and putting the Shim to rest

For those of you who have read about the Shim, you may be wondering if the Shim is the only way to access the Glasswall product. Well…the simple answer is “no”. As a matter of fact the Shim should act only as a temporary form of interaction throughout a transition between V1.0 and V2.0 in an organisation, allowing you to work the functions from V2.0. But, it is important to always have it in mind that you will be using the V2.0 without the need of a Shim.

Shim Recap

The Shim is currently used in Glasswall as a middle layer which enables Core 2 functions to be executed underneath the Core 1 code. This is a great way of using the Core 2 API without the need of removing or changing the Core 1 API code.

The limitation of the Shim

A major limitation that the Shim presents is that the functions must exist between one API to another. What this means is that if there are new features that Core 2 API is using which Core 1 API does not have, they will not be able to be accessed through the Shim.

Why Glasswall’s Core 2?

On a very high level, the Glasswall core engine is used for processing any number of files of any file type, breaking down any file down to its core, performing structural validation, content based sanitisation, and regenerating the file with a report.

Core 2 is a new and improved version of the standard product providing improved versions of the existing features and more. The Glasswall Core 2 product is the engine behind Glasswall. I will show below a comparison between Core 1 API and Core 2 API and showing you what you will be getting from using Core 2 API directly which you wouldn’t otherwise get from the Shim.

Core 1

1. Core 1 API was created as a very large segment with strong coupling between the Core and its interconnected functions and features. This meant any changes, additional features, or API functions, resulted in the entire Glasswall product needing to be completely regenerated because everything lived within a single library.
2. The important thing to mention is that Core 2 has a core product which is the foundation, and many separate entities which can be seen as sub-products which use the core. The way that I like to look at this is as a tree with a master node that has connecting sub-nodes (each node implements a feature). However, with the Core 1 API everything is packed into a single library without any sub-libraries.

Core 2

1. Loose coupling — each product Glasswall offers, such as the file type selection, security tagging, etc., is isolated into its own package and has its own library. So, if you think of it in the concept of nodes again, you have a centre node and many sub-nodes. Therefore, it becomes very easy to activate and deactivate features allowing Glasswall in having complete control in providing customers with bespoke products. For example, each file type has its own library which makes improving or creating file types much simpler.
2. All new innovation is isolated to its own library with Core 2.
3. Customers using the Core 2 API directly will be receiving consistent updates on existing and new features and products. Core 1 API will no longer be receiving regular updates.

To summarise, as you can see from the above comparison and high-level diagram, everything the Shim provides is only a fraction of what users of Core 2 API would have access to and there is a lot more to gain from making use of the latest Core 2 API.

Stop it. Block it. Glasswall it.