UPDATED June 14 2007 (check update further down)!

The last days another riot have happened in the CodeGear non-tech newsgroup. Yet again!

The relationship between a vendor and a consumer should be healthy. The vendor make decisions thats supposed to be for the benefit of the majority of its consumers and other potential consumers not yet in the fold. Sometimes those decisions are annoying some consumers or even hurting them to some extent. Hence the consumer ofcourse will need to voice his or hers opinion on whats going on and that its hurting the consumer. Thats a natural right in an open society with freedom of speech etc.

However there is a fine line between expressing ones opinions and terrorising the community. Disgruntled consumers are almost as dangerous as disgruntled employees... they can make alot of harm. The difference is imo however that the consumer often still have things at stake... existing codebases etc. and essentially often would have liked CodeGear to be successful of the simple reason that then the chance of the consumer to be successful with the current codebase is higher.

Hence its completely incomprehensible to me that all the so called Delphi lovers are so busy as they are damaging CodeGear by diminishing Delphi. Sure Delphi has had its rough edges in the D8 and D2005 releases, but the issues have been dealt with by CodeGear who obviously are aware about the problems and knows its in their interest to get those issues solved. Hence D2007 and Update 1.

Im personally quite annoyed about the way the critisism is expressed. Why do I care? Because I am a consumer of CodeGear products, and the company I work in is producing products consumed by thousands of CodeGear consumers too. Hence what damages CodeGear sales directly damages us and our customers. And I simply wont accept that, regardless of that Im in agreement with some of the elements that have been expressed by others regarding what would be good to have in a CodeGear roadmap like Linux/Cross compilation support etc.

The constant negative aura around CodeGear's non-tech group says to me that CodeGear is better of shutting it down permanently. Although sometimes being entertaining to read, its surely not doing CodeGear or its customers any good.

The article I wrote about a year ago 'The story of 3rdparty announcements and reactions on them' which is still available on our website at:

http://www.components4programmers.com/articles/thestoryof3rdpartyannouncementsa.htm

can be directly applied to whats going on between CodeGear as the vendor and its consumers.

UPDATE June 14 2007:

The responses I get on this blog entry, both as comments here and on the CodeGear nontech newsgroups, makes me realize that people dont seem to understand the effect that extremely negative posts in vast amounts can have. Its a misconception that just because its on a non-tech newsgroup, only the geeks will read it. WRONG. The non-tech newsgroup is being cached into several web based search machines, including Google Groups. Try to search for CodeGear and order the search by date.... the top 6 entries are all providing the probing potential new customer with a negative view on everything related to CodeGear.

Some people may be smart enough to read thru the bulls..t, but managers arent always that smart and as they may already be biased away from CodeGear, this number of negative posts will just be the final proof they need to convince their bosses that... "dont go the CG way... Ive read comments from their customers... and they dont believe in CG or its products... too risky to go there".

I welcome constructive discussions about features and techniques... but please.... grow up and dont act like a child when things dont go your way! As CodeGear have multiple times said.... single customers cant possible have any idea about why CodeGear make their business decisions the way they do, so continuing to whine about it wont do any good, on the contrare. No doubt that every community served by CodeGear, that being Delphi developers, C++ developers, PHP developers, Java developers etc. wants to feel that CodeGear takes special good care about them. However try to look at your own company... how does that operate? Are you able to provide specially good care for all your customers at once?... specially if the demanding ones are numerous? and very vocal? No.. .you will have to prioritize... and so does CodeGear.

Help yourself by helping CodeGear in the right way! Give them input but dont expect them to jump according to your tune as thats not how a company behaves. It receives the input, estimates the ups and downs of implementing the idea and then either accept, reject or postpone the idea. If you think you can do that better than CodeGear and being more economically successful than CodeGear, then you have an option for starting your own company. Do that... spend time on that... and realize how the world suddenly seems different when the problems and tough decisions start to pile up.

 

Kim

During the last several years, our flagship product, kbmMW, have been supporting more and more IDE's and versions, and it has also undergone a facelift in the sense that multiple editions were made available.

kbmMW currently consists of 2 packages (one runtime and one designtime) for each IDE for each edition. Each of those packages consists of one or two files. As kbmMW currently supports 10 different IDE's/variants (D5, D6, D7, D2005 Win32, D2005 .Net, D2006 Win32, D2006 .Net, D2007 Win32, C++ Builder 6, Kylix 3), and there are (or have been) 6 different flavours of kbmMW (OpenSource, Std, Pro, ProPlus, Ent, CodeGear), simple math makes the number of files to update each time a source file is renamed, deleted or added quite staggering. Its currently totalling around 100 files that must be updated!

That was starting to get REALLY boring to do, not to say time consuming and error prone. Automation must be the name of the day!

Hence we had to invest some time in a new product called kbmProject, which essentially is an advanced project file generator using scriptable templates.

In it we define:

• Units - which defines all the units that we know of for kbmMW as a whole. The unit definitions can also include information about forms/datamodules etc.
• Requirements - which define all the possible requirements that we know of for kbmMW as a whole.
• Projects - which we use for defining editions and what subset of the Units definition and Requirements they should contain.
• Templates - which defines the overall layout of the files. The templates can contain scripts and take advantage of variables/parameters defined on a job, project, template group, template, unit and snippet level etc.
• Template groups - which we use for defining groups of templates ... doh...
• Jobs - which is a combination of a Project and a Template Group

In addition we can define:

• Snippets - which essentially are small reusable code/data pieces that can be referenced from within a template
• Conditions - which for example can be used to indicate if a specific unit or requirement should be part of a specific package under some given conditions

When it all has been hooked up correctly, its as simple as clicking a Generate all button and all the relevant package files are generated automatically.

Quite neat!

This is a screenshot of the units pane... notice the raw unpolished look :)... its a good indication for this being a tool for toolers :)

And the following is a screenshot showing the templates and template groups.

As can be seen, the currently selected template simply contains a reference to the snippet BPK_kbmMW_Designtime. It could have contained alot more if needed, but I decided that I preferred the snippets to contain all the info as it would then be easily reusable.

So lets checkout the snippet then....

The snippet can be opened in a fullscreen editor to make it easier to read/edit.

 

Some places in this snippet there are references to either parameters or other snippets. The {%$=...} syntax references a parameter, and the {%$@....} references another snippet that will be inserted at that place.

The parameters can be defined on almost all elements in kbmProject. They are searched in a specific order to for example ensure that the parameter ANAME on the unit level takes precedence over ANAME (if defined) on job level etc.

The following show the scripted snippet SpaceLibsFroBpkPackage.

Anyway this was just to show you some of the extra tools we need to maintain continued development of kbmMW.

Kim/C4D

I've been building ASP.net web applications using kbmMW as the backend server since mid-2004.  All of the application servers have been Win32 based and of course the web frontend is dotnet based.  During this time I've used various techniques for transferring data between the tiers.

These include

• ASP.net built using Delphi for DotNet connecting to kbmMW using the Delphi based kbmMW clients exchanging data as VCL streams of objects
• ASP.net built using Delphi for DotNet connecting to kbmMW using the Delphi based kbmMW client using kbmMemtable DotNetAdditions (alpha) so that kbmMWQueries can be bound to directly
• ASP.net built using VS2005 and DotNet 2 using kbmMWSpider extensions for DotNet
• Something else I have codenamed Agility

What I'd like to share with you is the third of these because we will be releasing it very shortly after kbmMW 2.70.

It is a reality today that there is no CodeGear offering for developing DotNet applications for anything above version 1.1 of the framework.  However ASP.net 2 has some compelling features that we wish to tap into and certainly before the release of Highlander.

The clear choice then is VS2005 and C# as the programming language and then the kbmMWSpider client to connect to and interact with the application server. There is a problem with this approach though and that is the lack of kbmMemtable support running under dotnet 2.  After some pondering the solution was kbmMWSpider extensions for dotnet.

This is in use at http://www.myc4d.com/, http://www.turbomiddleware.com/ and some other interesting projects including an existing customer for their new web work (they contracted us to bring this forward in the roadmap). 

What is kbmMWSpider extensions for DotNet (yes we struggled with a name for this). 

It is comprised of three things

• an enhanced Spider C# client that supports connection pooling, request retries and failover
• a complete VCL compatible streaming layer
• two data formatters that accept kbmBinaryFormat (kbmMemtable in other words) and kbmMWFormat datastreams and decode these into System.Data.Datatable instances

In more detail

Enhanced Spider C# client that supports connection pooling, request retries and failover

An issue was dicovered when developing the portal.  Should the application server connection be lost for some reason the dotnet socket layer still reports the socket as being connected.  This sounds odd but in the world of sockets the only way generally to know if you're connection to the endpoint is valid is to attempt to send some data and see what happens.  If the connected property of the socket returned true then in anycase this would only be accurate at the point of the call - the socket could still lose it's connection a microsecond later. In the Delphi client we have robust handling of request failures with logic to retry the request and then attempt to failover to other servers.  The first incarnation of the Spider C# client didn't provide this logic so we have added it.

This issue was discovered because of another new feature added - connection pooling.  We now provide managed and transparent connection pooling to boost responsiveness and performance in high request situations. 

Anyone that has used TWriter/TReader in the VCL will know the power it provides.  It is also an integral part of the way kbmMW works.  Without this the scope for bridging the Visual Studio and VCL worlds is limited.

This is where the VCL support was trying to take us to.  Being able to make a request to a kbmMW application server, have it stream the results of a query into the resultstream and be able to decode and bind to this in the dotnet code.

Here is the real live deployed code for "mylicences.aspx" used in myC4D.com

Notice the line this.gridLicences.DataSource = dt line.  This is native data binding to the result of the MyLicences call.

Now the MyLicenceses call

Here is a regular request to a kbmMW application server that saves it's query results onto the resultstream.  In the ASP.net code we instantiate a C4D.kbmMW.Data.DataAdapter and get it to decode the contents using FillDatatable.  From this point on we have our data in a dotnet friendly form that we can bind to and manipulate. It is efficient and complete.

I'm looking for more people to play with this before release so if you're interested let me know.

Richard

We have had a few enquiries about the where abouts of kbmMW 2.70 so I thought I would explain what has been occuring.

As you are all aware we recently announced a whole new business model for our products.  The aim of this was explained in detail in the announcements.  It is something we have been discussing for a very long time and put off over and over again.  We finally made the announcements and were overwhelmed by the support and goodwill shown to us by our users expressed in the newsgroups, by email and directly to us on MSN and Skype.

It was then down to business - deliver 2.70.  This involved:-

1. finalising the myc4d.com portal

2. organising the server resources

3. code completing 2.70

4. biting the bullet and finalising kbmProject to manage the huge number of build scripts we have due to supporting all the Delphi/Kylix and soon FPC build configurations.

We were doing well on all four targets until I hit a few time issues and bugs in the new kbmMWSpider for DotNet and managed to miss the May 1 target for the portal.  I'll blog seperately on how this was built but it's very cool.  2 and 4 were completed.

Now down to 3.

In our wisdom we decided to add a wonderful new feature to kbmMW - AJAX support right out of the server.  Like any idea such as this it is a great idea until it isn't!  Suffice to say Kim ended up badly burnt by his bits and bytes but soon emerged with the goodies - it's looking good but the demo is not quite there yet.  Where we are at right now is trying to decide whether to make a 2.70 release and cut out the demo of the Ajax support and move that to a 2.71 or see if it can be sneaked into the release in the next day or two.  As Kim said "I would feel best releasing with the demo because then all the bits have been demonstrated to actually work rather than theoretically work" - enough said.

Suffice to say this delay is no fault of any of our customers so those that are on a 1 month SAU will be guaranteed access to the 2.70 release.

We will post a link to this very cool demo soon but to preview what we are doing here is the original version. What we will be showing very shortly is the same IM application running using all the same html, js, css, swf, graphics etc - in fact 100% the same content as the original but it will be communicating directly to and solely with a kbmMW server - it's impressive. For those that have worked with AJAX before you'll be interested to know this will also demonstrate how to use JSON directly out of Delphi

 

Richard

 

In quite a departure for us at Components4Developers we have decided to start blogging.  Day to day we constantly talk amongst ourselves about new ideas, techniques and ways to improve our products.  Some of these ideas get into the released code line, some get put into our research basket for a revisit and some get rejected.  Our customers though don’t see this process occurring, well that’s not quite true.  Customers that engage us in consultancy services get to see this first hand as often we are solving big issues for them through elegant additions to our products.

For example, the first internal implementation of the messaging in kbmMW was UDP based.  Why UDP?  - Because a customer commissioned us to extend the middleware to support publish/subscribe distribution of real-time video.

Another customer needed connectivity for PHP, C, C# etc from which came the Spider clients collection.

It is worth mentioning then that if you really need a feature added to any of our products you could always commission us to develop that for you on a shared IP basis.  If we think the feature will be of general benefit to our products then we will include it in the production source and maintain it through its life.  It never hurts to ask

Getting back to the blogs.  Here from time to time we will share with you some of the ideas we have in the works, or things we have noticed across the industry.  Or, we may just have a joke or a moan.

Everyone is invited to join in. We invite our C4D friends who wish to join our bloggers list to let us know and we'll setup an account for you. Those that would simply like to comment on, or syndicate our missives please go ahead.

On another note.  Theses blogs are powered by BlogEngine.net.  Check it out.  It is Open Source and based on ASP.net.  Maybe I'll find a reason to hook it up to a kbmMW application server sometime.

Richard and Kim