Re: Captain Jake's Top Ten List of what I'd like to see in the nextversionofDelphi


"Randy Magruder" <randy.magruder@xxxxxxxxx> wrote in message
news:44a57495$1@xxxxxxxxxxxxxxxxxxxxxxxxx
Nick Hodges (Borland/DevCo) wrote:

Randy Magruder wrote:

Problem is, you have NO idea how well it's going to work with the
database, what performance issues there are, whether the evolve
database strategy will work for you, etc...unless you have the
Enterprise product.

The real problem is we need to find the balance between value and what
goes in the SKU's. That's not an easy problem. I personally don't
have a problem with the "Goodies" creeping downward over time.

Nick,

As I mentioned, numerous component developers make their components
only work when the IDE is running? Why not have a non-time-bombed
version that only runs inside the IDE and cannot be deployed. You let
someone do everything tney need to do to learn the framework and get
hooked on it, and then when they want to 'go live' they can dish out
the money and upgrade Delphi.

Another approach would be to limit the SIZE of the tables that can be
created and maintained by an ECO app. If a persistence mapper tried to
write 1001 records and the 'eval' limit was 1000, it would fail.
Again, this becomes a scalability thing. The 'army of ones' get an
entirely useful 100% functional tool to use for hobbyist projects and
learning how the thing works, and the enterprise that is going to need
such limitations removed will get that too.

Ya gotta be creative, here, Nick. Simply adding or subtracting portions
of functionality in a situation where people are still trying to figure
out wot-the-hell ECO is just doesn't work.



Absolutely. Agree completely.

-d



.

Relevant Pages