Re: Extreme!!! Special timelimited competive upgrade offer

From: C4D - Kim Madsen (kbm_at_components4developers.com)
Date: 06/28/04 

Date: Mon, 28 Jun 2004 00:21:20 +0200

Alessandro,

> I was truly hoping in a peaceful co-existance in which both companies mind
> their own business without sneaky remarks, but that is apparently not
> possible. The "competition", as you call us, is not trying to catch up with
> you (or anybody else for that matter).

I was asked a direct question about why I think a RO user should look at kbmMW, and hence I answered.
Just for the record: I stated precisely where I refer to RO, and places where RO is not mentioned should be read as a
general clause.

> I am pretty sure ASTA or dbOvernet
> aren't either since they have their hands full of other exciting projects.

I have no idea what they are doing. I can only say that it certainly doesnt look like its in the n-tier buisness as
there have been no updates, no news no nothing from them for a long time. I personally do not see much happening in each
camp... being a dbOvernet customer (long time back), I would even have the right to say that Im very disappointed by the
level of releases from that side.

> We have a precise schedule of features we want to develop and know when it
> makes sense to develop them. It's not by accident we were the *first*
> company in this market segment with a roadmap and we are, as of now, the
> only one who *updates it* and have it well visible on the home page.

Not sure that Asta and just about any other company delivering any type of communication tool would agree with you.
Most have a roadmap. Some hidden some not, but claiming you were first must be a bit of a joke, right?

> Adding hundreds of features one after the other, bloating our products with drivers
> for every possible component set on Earth is not a goal of ours. We do the
> important ones and do them well.

Im never going to tell you how you are to run your business, Im sure you know that much better than me. That doesnt
change that C4D may have another view on it though. Just to set things straight... offering features doesnt mean
bloating a product unless the implementer is really bad in implementing them. Wondering about what you will call it the
moment you actually _do_ have those features... will it still be bloat?

Im confident that our kbmMW customers are very happy about having choise without having to rewrite their applications or
have to do all the coding themselfs to support something.

> That is one of our goals. Online articles,
> FAQs and support is much more important to us, since that is what the
> customers expect and pay for on top of the technology. The bigger the
> customer, the more important this becomes.

Sure, support is extremely important, and from what Ive heard, your company certainly gets good comments about that.

> You keep talking about the needs of "Enterprises". We address the needs of
> the single developer and corporate teams, regardless of how "Enterprise"
> they are. We charge a price that allows them to buy our products and ensure
> that the company can make investments in R&D, new personnel and
> documentation. For example, it allows staffing of support to cover holidays
> and illness - customers know that their needs will be addressed in a timely
> manner. That is what a real "reasonable pricing" allows companies to do.

Each company have their own ways of doing things. You dont have to justify your way to me.

> "Much better support" has to be seen. "More options" (server side) is more
> like it. We choose not to spend time in doing server side load balancing
> mainly because the market has plenty of network load balancers already and
> we have better things to do than to reinvent the wheel. Besides most people
> who need it already have hardware to support it.

Hence... RO doesnt support the same loadbalancing facilities as kbmMW does out of the box. Whats wrong with my statement
then?

> What was important was to ensure RO was stateless and could work in web
> farms. We did that since day one and we also worked hard ensuring that our
> customers *understood* why stateless is important and what you can achieve
> with proper nTier designs. A complete load balancer architecture has to
> consider elements such as distributed transactions and the CPU server load.
> I gave a quick glance at your papers but there's no trace of information
> like this. RO has everything needed to ensure 24x7 uptime to RO clients.

Sure, statelessness is an important thing in n-tier products for scalability reasons.
Our loadbalancer structure actually is capable of loadbalacing according to load on servers, and the cool part is that
the loadbalancing techniques are, like with everything else in kbmMW, extremely extendable. Thus I would say that about
any interesting loadbalancing strategy easily can be implemented in kbmMW.

> I am not sure what you mean by "Automated proxying", but we show how to do
> tunnelling in one of our demos.

Well.. its actually relatively simple, but very nice to be able to do, specially when its able to work with just about
any transport mechanism available.
Proxying is to have one server proxy a request to another server, acting as a middle man. Im sure somebody will shout
'HEY... that means single point of failure, worse performance' etc. etc. and yes, thats correct.... if not coupled with
our advanced loadbalancing techniques which works on both sides of the proxy.
As said, proxying is really a simple operation, but kbmMW handles that out of the box without any coding.

>
> > - True publish/subscribe messaging... RO havnt got anything similar.
> > Will allow you to use one port for messaging, request/response and
> > more on LAN, WAN and internet.
>
> UDP and TCP/IP messaging doesn't work well over secure WANs or Internet
> because of firewall problems. Your publish/subscribe mechanism seems to be
> based on that. We offer a stateless poll-based queueing mechanism that works
> regardless of clusters, firewalls or network configurations, in WAN, LAN and
> other environments. In addition, we have had UDP broadcasts for over a year
> and direct callbacks for LAN as well.

Publish/subscribe messaging is _SO_ much more than just polling and callback. UDP messaging is certainly not very
firewall friendly, but our TCP/IP based hub/spoke is. But the point is that its more than _just_ a transport layer as
such... its a widely useful concept utilized by the largest companies in the world for their core business networks. The
understanding and uspport of this concept is what marks some of the differences in true enterprise level n-tier
libraries.

>
> > - Many more database API's supported.
>
> Already addressed above.

Yep.

>
> > - Much more complete metadata handling.
>
> Our RODL metadata (http://www.remobjects.com?ro18) is fully accessible,
> allows for cross-language and cross-platform interoperability (C#, Delphi,
> ANSI C and Turbo Pascal are some examples of the existing client ports) and
> we have a layer of remoting that allows for full interception and aspect

ok.. it seems I havnt expressed my self clearly enough. Im talking about metadata for database support.

>
> > - Direct Java support on server side.
>
> We've had support for that and much more since version 1.0 because we
> implemented SOAP messaging immediately.

This has nothing to do with our Java support. kbmMW supports business code _written_ in Java, and thus can act as a Java
application server although not JREE compatible.

>
> > - The fastest memory datastorage.
>
> Our architecture allows our customers to use the in memory dataset of their
> choice. TClientDataset, TADODataset, AidAim's, NexusDB's, etc have data
> table wrappers and so does your KBMDataset probably. Writing a data table
> wrapper is a 30 minutes exercise and that allows our customers to choose the
> best tool for the job rather than forcing one option only.

And ends up in only being able to use the lowest common denominator.
BTW. Its kbmMemTable, not KBMDataset.

>
> > - Complete file service handling.
>
> I don't find the ability to stream files up and down the wire something so
> exciting or compelling, sorry. RO supports streaming in a very flexible
> manner already and we have more exciting functionality in the works than
> that.

Sure.. but kbmMW is not used by you, but by lots of other people who seemingly have a different view than you on this.
Sorry... C4D dont design kbmMW according to what you find is 'right', but rather according to what many years of
acquired knowledge about large scale development in criticial enterprise setups and from what our customers are asking
from us.

>
> > - Advanced, but easy to use server and client side caching functionality.
>
> Which we will introduce in Data Abstract 3, along with a multi threaded
> oriented data storage object which doesn't suffer from the limitations of
> TDataset(s).

Hrm... catching up on caching :) Sorry couldnt resist. kbmMW have had that since day 1... some years ago now. 

-- 
best regards
Kim Madsen
kbm@components4developers.com
www.components4developers.com
The best components for the best developers
kbmMW          - RAD Enterprise class n-tier application server framework
kbmMemTable - High performance memory table
kbmWABD      - RAD web development
kbmX10           - RAD house automation
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.711 / Virus Database: 467 - Release Date: 26-06-2004

Relevant Pages

  • Re: Oursourcing helpdesk services
    ... majority of customers that they would piss off due to poor customer service, ... I've had many hair-pulling email encounters with Amazon.ca's support ... I can only assume that big business has figured out that losing good ... The only difference between humans living in the year 2006 ...
    (borland.public.delphi.non-technical)
  • Re: Revival of Alpha?
    ... >>running VAXs. ... >>HP and when support ... >>customers, there is considerable value in their applications, and for ... mind having your software dictate how you run your business. ...
    (comp.os.vms)
  • Re: Port to z/OS or OMVS?
    ... Business users make the decision on what is good for the business. ... We (as tech support) may be asked for input, ... > porting this server to native z/OS? ... is this a scarce/costly resource for customers? ...
    (bit.listserv.ibm-main)
  • Re: Is silence golden?
    ... HP is still in the support business in 2007 and 2008, but it will be "basic reactive" support, unless you need mission-critical enterprise level support. ... For most customers, asking HP to extend their support contracts is all it's going to take to get the vendor's support for two extra years. ... No proof of migration plan, no promise to buy HP systems to replace your 3000. ...
    (comp.sys.hp.mpe)
  • Re: Special upgrade treatment
    ... If technical support is recommending against any other ... | updates in that series or in any wider selected range of update ... customers, and the quality of LW releases is of public interest. ... and your bug backlog dry up. ...
    (comp.graphics.apps.lightwave)