Re: Extreme!!! Special timelimited competive upgrade offer
From: Alessandro Federici [RemObjects Software] (alef_at_rem_________objects.com)
Date: 06/27/04
- Next message: Reinhold Erlacher: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Previous message: Bob: "Re: Database suggestions?"
- In reply to: C4D - Kim Madsen: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Next in thread: Peter Morris [Droopy eyes software]: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Reply: Peter Morris [Droopy eyes software]: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Reply: William Meyer: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Reply: C4D - Kim Madsen: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Reply: Bob: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Reply: vavan: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 27 Jun 2004 15:17:13 -0500
"C4D - Kim Madsen" <kbm@components4developers.com
(kbmMW/kbmMemTable/kbmWABD/kbmX10)> wrote in message
news:40dd68ac$1@newsgroups.borland.com...
Kim,
> Big words, but Im not kidding.
> Some examples often required in enterprise setups where competition is
trying to catch up:
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 am pretty sure ASTA or dbOvernet
aren't either since they have their hands full of other exciting projects.
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. 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. 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.
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.
> - Automated loadbalancing... only recently RO have added a
> loadbalancing look alike. kbmMW has much better support for different
> LB schemes.
"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.
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.
> - Automated proxying... very handy for hiding your server park from
> external visibility, and for tunneling requests through.
I am not sure what you mean by "Automated proxying", but we show how to do
tunnelling in one of our demos.
> - 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.
> - Many more database API's supported.
Already addressed above.
> - 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
oriented programming (http://www.remobjects.com?ro15). You can choose to use
our remote objects as *objects* (and thus take advantage of the IDE features
such as code completion and be able to use strong typing) or via RPC like
your objects. It's a customer choice on how to proceed (weakly typed and on
their own, or strongly typed and object oriented). Tools such as the Service
Builder and the Schema Modeler greatly help developer teams to see what they
are working on/with and also generate documentation. The pluggable nature of
our tools also allow for customers to extend this functionality by writing
their own plugins.
Data Abstract 3 actually brings this a step forward by introducing full
diagramming support, previously only seen in tools such as ECO etc. More at
http://www.remobjects.com?DA14
> - 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.
> - 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.
> - 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.
> - 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).
> - Much lower entry price. You dont need RO+DA, you get it all + a
> whole lot more
> - Much more reasonable upgrade policies.
Already addressed above.
> + many more areas.
Same here. For all those interested we've plenty of documentation at
http://www.remobjects.com/articles/
Best regards,
Alessandro Federici
- Next message: Reinhold Erlacher: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Previous message: Bob: "Re: Database suggestions?"
- In reply to: C4D - Kim Madsen: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Next in thread: Peter Morris [Droopy eyes software]: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Reply: Peter Morris [Droopy eyes software]: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Reply: William Meyer: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Reply: C4D - Kim Madsen: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Reply: Bob: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Reply: vavan: "Re: Extreme!!! Special timelimited competive upgrade offer"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|