9 years and one month of Concept Application Server

It's been 9 years since I've started this project. Now is mature, tested in high load environments, over a hundred end-user solutions implemented by myself. There's a lot of new stuff, both in Concept Application Server and GyroGears.

For start, Concept 3.0 is almost here, with lots of new features. The main star is the new Concept Client for iOS.

 

For Gyro, lots of bug fixes and a new UI model for child entities was added. Now, you can show all the info using the same window (without opening new child windows). It's a tab-bar style view.

Also, drag-and-drop of files/images is now cleaner.

Mobile applications generated by GyroGears are now read/write, and use the same source code and binary for both Android and iOS.

DRM API's are available in beta, as a new feature in Concept 3.0.

Concept Client for OS X 10.8 is now up-to-date, and soon a binary packet for Concept Application Server will be available for OS X.

Concept 2.4

Concept 2.4 now available for download. As the main feature is the new JIT (sljit), and some basic code optimization (like dead-code elimination).

It almost tripled its speed since the first version with JIT. Here is an example for a basic benchmark for arrays + basic operations (lower the better):

About 6 times faster than PHP 5.4 and about the same speed with C (gcc, no optimizations).

I've also ran a Sieve benchmark (higher, the better):

The slight advantage for gcc comes from the fact that Concept core must call a function for accessing array elements, instead of a direct access (like in C/C++).

For now is fast enough for Concept to be a reasonable choice for CPU-intensive computations.

Average speed optimization for Concept/JIT is about 800%, but in some particular cases it is more than 2000%.

Concept Application Server 2.4 with 3.0 core

I've made a few tests with various programming and scripting languages (C/C++, IonMonkey, Chrome V8, Java, PHP 5.4). I've used an implementation for the sieve of Eratosthenes algorithm for the benchmark. As an unexpected result, IonMonkey (Firefox 18 javascript engine) was insanely fast (around C speed).

As a result, Concept now has a JIT compiler, that fully compiles a function upon the second run. For the standard benchmark (strings + arrays + arithmetic operations + objects) some impressive improvements were noticed. For example, arithmetic operations are about 2000% faster. Function call (context create and free) about 50% faster. Array operations are slightly faster for numbers, the same for strings. String operations already optimized remain the same. Object method call (including constructor call) about 25% faster by reusing memory (instead of freeing the memory, is conserved for the next call, same with objects). So, for the Sieve of Erathostenes repeated 900 times, these are the results (lower, the better):

As you can see, the benefits for using JIT are massive. I've chosen to use an existing JIT (Stack-less JIT compiler). It's incredibly simple and clean, and it took me about 2 days to link it to the Concept Core.
As a note, for PHP, if the Sieve interval is extended from 8193 to 1,000,000 primes, the execution time raises exponentially (v5.4 about 580 seconds, Concept with JIT about 30 seconds). A low interval was chosen as representative for real-life situations.

For GyroGears, bug fixes and a new feature: import from CSV for related members and export to Excel.

For now, Concept 2.4 with JIT compiler is available for download.

GyroGears and new driver

A new "old" database server is supported (without ODBC) both by Concept Application Server and GyroGears: Firebird. It's been a while since I've tested Firebird (and then, it was 1.5 I think) and there were some problems, especially with the "hard-to-use" driver. Now, 2.5 it works great. It still has some limitations, for example maximum column and table name length is only 31. That's now fine with Gyro (it automatically removes characters from the table names).

Now, Gyro has lots of goodies for the end-user:

For example, the nagging "You forgot to enter Name, Email, etc." window, has been replaced with a red ribbon and highlighting the field. A "switch to fullscreen" button was added that enables you to hide the toolbar. You can also see the new "Single pane" layout, that enables you to use the same space for views and actual forms avoiding opening a new window.

A feature search panel eases the menu access. The use can just search all the features in an application.

In Gyro, in all numeric members (integer and decimal) you can now enter formulas, for example, if you enter: 2+2*2 it will be automatically evaluated to 6.

The server now compiles on Windows 64-bit. Due to some differences, it didn't compile on 64bit Windows. However, on FreeBSD 64 and Linux 64 worked just fine.

Usability++

I've added hunspell wrappers in Concept Framework (http://www.radgs.com/docs/help/standard.lib.hunspell.html).

Also, I've added into standard.lib.str Soundes, Metaphone and DoubleMetaphone functions.

I've added a few new gadgets in GyroGears applications.

1. Autocorrect in search fields (works for almost every language - defaults comes with English (US+GB) and Romanian.

2. Spell checker in text views.

3. Shortcuts for adding in relation members (see the above screenshots).

4. Beautify solution for GyroGears. This beautifies your app (aligns labels, chose which columns to be visible by default in views and so on).

GyroGears and usability

I've had some crazy requests in the last few months. The users (end-users) complained about the usability of Gyro applications, and in some aspects they were right.

1. Latest complaint: interfaces are ugly, so I'm working at new ones. 

This is the new main applications screen:



If you think it looks like something, rest assured it is not.

2.  The calendar is useless.

I redesigned the calendar. Now it looks like a classic calendar widget, with drag and drop (you can now reschedule an event by moving it to another day/hour).

3. Database search - redesigned

Pattern search now applies to spaces. So, if somebody looks for "Mikey Mouse", "Mickey The Mouse" will be also returned.

Three new options for entities in GyroGears:
- search by parent
- show parent as a chain
- child search level

Let's consider a client who has contracts. In the contracts master view, I can now type the client's name, and it will return all of its contracts. Same logic for child search level. For example, in the client list, I can enter a contract number and see the client with that contract number.

A few version ago I added "Show parent" options. This way, in a master view, on the first column the parent entity representative member will be shown. But, if parent level was 2 or more, only the final parent shall be shown. When the "show parent as chain", all the parents will be shown. For example, a client, has contracts and on every contract has a service. This way, on the service view, in the parent column, both the contract number and client name will be shown.

4. Horrible Glade for UI design (developers).

Until now I used glade-window as a method for embedding Glade into CIDE (Concept IDE). This meant that on every new Glade version I had to modify the sources.

So, I've wrote my own "glade-window.

Also GTK3 is now used on Windows too.


5. Editable ComboBoxes for many to one relations

For many to one relations you could set in GyroGears "use a combo". Now, you can also set "editable combo box". This way the user can perform a quick look-up for the given member.

6. Too many "Save" buttons for modifying a child object

When you check "enable send to" for a relation, now you get this cool context menu.

This enables the used to add a child object, without editing the parent (and so, avoiding a lock).

7. Localization and international support.

A company in Jordan has Arab employees and Romanian management. So, for the same application, two different languages were needed. This was already fine with Gyro. Now is perfect.

Also, date and time can now be formatted. (Eg: %d/%m/%Y %H:%M).

8. Telephony integration

I've added a SIPPhone class in the Concept Framework. This allows you to initiate a call, answer one and talk using a high level interface.

This is somehow cool if we talk about a CRM, and the client calls in. Then, the application automatically detects the client and opens his or her records.

9. Button press feedback for image buttons on mobile client

A friend of mine tried Concept Client Mobile. He complained about the lack of feedback when he pressed an image button. So, I've added a gray tint when the button was pressed.

10. Flash in WKB (Concept Webkit Browser) on Windows (thanks to Midori)

WebKitGtk finally works as it should on Windows. Also, the left key doesn't hang up the WYSIWYG editors.

This week I will modify the data input interface and add keyboard shortcuts for various operations.

New features for GyroGears

I've spent nearly 80 hours talking with GyroGears users (both programmers and non-programmers). A year ago the support for smarty-like templates was dropped in favor of XSLT. Then I used Sablotron but switched later to libxslt2 (easier to install). Now, the developers asked me about the possibility of calling Concept functions from XSLT, and I've said no. Not because is not possible, but because I consider it bad practice. However I've been asked about this so many times that I've decided to implement it. I've made a very simple interface - just one function that registers all members of a class:

XSLTRegister(object[, alias, namespace]).

So, you can just call XSLTRegister(this) and you will be able to call from the XSLT every function.

Also, Gyro now generates interfaces functions for XSLT. You could call something like:

<xsl:variable name="invoices" select="csp:WU_Client.GetInvoices(__DBID)"/>

Or even:
<xsl:variable name="clients" select="csp:WU_Client.Search('some client name')"/>

And then:

<xsl:for-each select="invoices/array/element">
   Amount: <xsl:value-of select="invoices/array/element/Amount"/>
</xsl:for-each>




Also, 3 features were implemented:

Reorderable flag for entities (you can reorder objects by drag and drop - lots of fun playing with this one) and reorderable flag for relations (just for non-exclusive ones). This allows the user to reorder objects in related views without affecting the master view order.

The third one - a flag for linking an object list to every HTTP script (for example an entity called "Menu" with this flag set to true will cause the menu items to be linked to every script.

As usual lots of bugs fixed. One was linked with the usage of filters on relation fields.

Android Client and GyroGears Mobile

It's ready and it's cool. Concept Client Android version is available for download (just use your Android device and visit www.devronium.com and download Concept Client. I've managed to make it fully compatible with the existing Concept Framework.

This means that GyroGears can automatically generate Android Applications.

Take a look at how it looks:

 

Just remember that everything (except the last one) is automatically generated by GyroGears in only a few seconds.

The last screenshot is my telephony application based entirely on Concept Application Server (even the Telephony server is Concept-based)..

Concept Client 2.0 Android Beta1

After implementing 2 mobile clients, one based on MoSync and another one based on Marmalade, I've decided to implement using "the native way". I've made the Concept Client 2.0 for Android devices using only Android SDK and NDK (the socket layer).

After looking into MoSync, I can say that is a nice platform but with a big drawback: the sockets. They implement AsyncSocket and it is a good idea, however, this cannot be a solution for every situation. Just think at a VoIP application.

On the other hand, Marmalade has better sockets and low level APIs, and is significantly faster. However the support is almost zero (Maybe for enterprise licenses is different). Also, the native user interface (IwNUI) it lacks lots of functionality. Audio API's are almost impossible to use, at least if we're talking about streaming (you cannot use locks in audio callbacks).

Now, Android SDK and NDK is straight forward. I've ported the client in about 7 days, which is fine. Next to come is iOS.

This is from a VoIP application that I'm working on - entirely Concept Application Server - based.

8 years of Concept

It's been 8 years from the first working version of Concept. Now, it's mature, stable, feature rich and used in production in over 200 applications.

As usual lots of bug-fixes, and new features:

• a bug in MySQL interface library that caused a crash when reading blobs of considerable size
• UDP socket support
• New multi-threading core library (uses the same code base - it must be compiled with -DSIMPLE_MULTI_THREADING). With this option you can create applications that are writing to the same variables without any need of semaphores. The speed penalty for non-threaded scripts is under 5% and but when running a multi-threaded script, the penalty can range from 5% to 100% depending on number of memory writes. For usual applications is about 6% to 10%. Also, there is no memory overhead.
• Faster Garbage Collector (hundreds of time faster) by replacing the pointer list with std::set. - About 7% less memory used. The optimization is made on variables, 32 bits less memory used by each string variables and 64 bits less for each non-string variable.
• SIP stack library ported to Concept (work in progress) Now, the really cool new feature is in GyroGears. For every generated application it automatically generates the migration script for SQL-based database. NoSQL is to come, and automatic migration from SQL to NoSQL. The problem with NoSQL (MongoDB) is that it uses a different id-system, and the migration cannot be done one to one. Now, you can move from one server to another and back in a few minutes. It supports MySQL, PostgreSQL, SQLite, NuoDB, ODBC amd Firebird (via ODBC). For migration, you just run the required script in migrate.prev folder (ServerRoot/MyProjects/YourAppName/migrate.prev). 

Here's a multi-threading example using the concept MT core - as you will see, no semaphore are used for threads accessing the same variables.