In today’s post about the recent release of Cairngorm 2.2, I’ll give the reasoning behind the most obvious change made to the distrubution of the framework – the splitting of it into two parts, Cairngorm and Cairngorm Enterprise.
The main reason for the change at this time was to remove Cairngorm’s dependancy, introduced in Cairngorm 2.1, on the Flex Data Management Services library, fds.swc. This dependency forced developers to download Flex Data Services, even if they were using Cairngorm with a relatively simple applications that used RemoteObject, HTTPService or WebService only.
Mea culpa, as they once said.
However, this change also hints at the longer term roadmap view of where Cairngorm is heading.
Our vision is that Cairngorm will have a core framework, which mid-sized applications will use. Alongside that, we foresee the need for a set of additional modules, for use in enterprise-scale applications.
These modules will contain repeatable, best-practice solutions to common application problems and will address areas such as:
- Extended support for Flex Data Management Services
- Extended support for Flex Messaging Services
- Platform specific module for Apollo
- Product specific module for LiveCycle Enterprise Suite
- Security and authentication modules
- Others we haven’t thought about yet
The modules could vary in architecture, from a simple set of command, delegate and service definitions, or even some server side Java code (eg, for LiveCycle ES), through to new sets of classes that implement the common patterns we see emerging in our solutions.
We expect the modules to surface as best practices out of our day-to-day consulting work, rather than by us attempting to determine the solutions upfront. As such, we cannot commit to any specific date for any new features, but we can say that they will remain free and open-source.
As always, we welcome your feedback on our thoughts.