Virtual Affairs LTD and the VA Security System

I almost setup my new place called Virtual Affairs LTD.This is the place, where I will run my business from.
The first thing(after the more important ones) to do for my place was to create a security system for it. My first goal was to place a number of doors around the office to restrict(or allow) the physical acces to specific areas (customers area, stuff area, owner area, etc.)
I had the following requirements at first:

1.Functional:
1.1. Having multiple doors placed around my office
2.2. Controlling all the doors remotely within my place- one by one or all at once
2.3. Delegate rights to my security officers to control the system
2.4. Controlling the access rights from a single point for the whole system.
2.5. Monitoring doors states and the passing avatar names

2. Technical
- 2.1. Avoid performance penalties due to the built-in LSL functions delays
- 2.2. Avoid performance penalties in large setups (many many doors)
- 2.3. Extensibility of the systems in specific points: Custom monitoring devices, Custom physical restriction devices(doors, windows, pikes, etc.)

So, I spent few days and finally created my security system and called it "The VA Security System". In result of the functional requirements I have now a system ( which actually turns out to has more features than I originally planned), which allows me to create access rules on from avatar/door level to everyone/everydoor level. It allows me to easily delegate control rights to my stuff and controlling and monitoring the system from anyplace within my office.

As we have built-in delays in LSL script functions , I had to find a strategy to overcome this problem especially, when dealing with server-door and server-monitor communications(2.1).
The good news for me was that the LSL developer may utilize a kind of asyncrhonous-processing strategy by using multiple scripts into a single prim and llMessageLinked function.
The other technical problem(2.2.) was to reduce lagging, when dealing with large number of connected doors and huds. This was more about considering the overall architecture of the system. I had a functional requirement to have a single access control point - e.g. one place to configure, who may have access and who may not have access. My first implication was that this requirement forces me to utilize a highly-centralized architecture, where the core layer(server) will be the bottom neck of the system from a performance point of view. Fortunately, I was able to take another path and use a more distributed architecture. The system components are slighly more complicated, however the server component is far more simple and fast.
The interesting part here is that the system is still highly centralized from a functional point of view(e.g. the user poing if view). It is still controlled from a single place, but the core functionality is actually distributed under the hood, between the system components.

I installed it on my place and conducted some tests for few days. Then I decided to release it commercially. It is published on slexchange.

It is the first release of the system and I'm more focused on creating a robust and extensible core for the system. I plan to add more features as well in order to get tighter control over my place.
I provide installation assistance and on-going support for the system as well.
Want to test the system? There is a live demo in my office.