Pretty admirable strategy Eliot, but where does it fit in to the picture
for somebody building an application for a company who don't have the
time or $ for this approach??? As per most of our NZ customers.
I have not been fortunate enough to be involved in a team using your
approach, but would be interested in hearing more. By the way, the book
you recommended to me is excellent thanks.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Eliot Muir
Sent: Thursday, 22 April 1999 08:42
To: Multiple recipients of list delphi
Subject: Re: [DUG]: How thin the client will be?
I never take it for granted that any product from any
company actually
works. All of the big software companies are guilty of
marketing technologies
which don't work. They have to make money - there is
nothing worse from
there point of view than developers who are quite happy
with the nice stable
libraries they've built over time - it's hard to sell
the latest wizzbang set
of
new tools.
I remember years ago getting rather burned by using
databound controls in
Delphi - they just fell over with multiple users and I
know Ian Farquharson
& co ended up spending much of their time
at Profax rewriting chunks of the Delphi data base
system.
On the other hand I worked for Credit Suisse Financial
Products in London
a department with over 170 developers that had a hugely
successful model that
kept hundreds of complex inter-connected systems working
over a long time
frame.
Servers were written in C++ under Unix - which is fine -
C++ is actually a
a fine language for writing non-graphical code - it's
hard for GUIs because all
the standard class libraries and tools are piss poor
(MFC is crap) The
networking
layer was implemented using an in house library which
streamed C++ objects
over RPC - clients were usually written in VB speaking
to a thin COM wrapper
around the client C++ stub.
With design the clients could be rapidly changed -
redeveloped and chucked
away when not needed - any client could talk to our
servers - we had Lotus 123
Unix
spreadsheet clients, MFC clients, Excel etc.
The server technology on the other had was stable -
which was important - those
systems were very inter-dependent - Credit Suisse could
not afford to have them
broken
by a vendor decision to cease supporting a particular
technology.
Once you've developed one of these networking libraries
you've got it for life
- I never
touched a single line of networking code at Credit
Suisse because the library
had already
be done.
It all depends on your timeframe - if it's a tactical
app that you need to get
out the door and
you're going to chuck away after a couple of months,
then throw the dice and
try out a vendor
technology. If your app is going to be around for the
medium to long term, if
you might have
a requirement for other clients other than Delphi in the
future - go for a
simple homegrown
approach.
Frankly I think in the time it it would take me to learn
MIDAS I could write my
own networking
layer <grin>
Cheers,
Eliot
--
Eliot Muir
iNTERFACEWARE
mailto:[EMAIL PROTECTED]
Voice 64-9-5202077
http://www.interfaceware.com
Makers of HL7 Chameleon
"Program to the iNTERFACE not the the implementation"
I would personally be very cautious about taking for
granted anyt
corporation - there
numerous examples of technologies marketed by Microsoft,
Borland don't
actually work
I think often these decisions come down to the size of
the organisation and the
length of time the applications have to last. I worked
for Credit Suisse
Financial
Products in London which utilised quite a careful
structure of servers written
in
C++
I guess depends what background you're coming from - the
approach I described
worked very well for Credit Suisse I worked for in
London.
We followed the architecture of backend servers written
in C++,
[EMAIL PROTECTED] wrote:
> I love this argument because I can see both sides...
>
> I have always used bound controls in VB and Delphi.
With Delphi we use
> Midas because it works and it saved many man many
hours creating our own
> version of something that we felt Borland/Inprise new
how to do better than
> we did. In the end, it probably has cost about the
same. Another
> advantage is that there are many developers using
Midas and most problems
> are solved before we encounter them.
>
> We use 2 third party libraries (SPIS TCompress and
Async Pro). Everthing
> else we created ourself because we couldn't but it or
we found free source
> to do what we wanted.
>
> Sure, Inprise could go broke or Midas may be radically
altered but what we
> have works now and there is no reason to dump it just
cause there is a
> cooler tool or new version. Most of our code is still
Delphi 3.
>
> Also, with any design, the OS may change (as it
frequently does these days)
> and code will probably break. No software is an
island...
>
> As for scalability, having a ui control data-aware
does not effect
> scalability, it's what you do with it that matters.
For example, grids are
> normally very dangerous with traditional C/S 2 tier
apps. With Midas, you
> have complete control over what get's into the grid
and how updates are
> dispatched to the server. The only thing you can't
control is the midas
> data packets structure over the wire - but you can
easily control when and
> how much is transmitted. I haven't seen anything else
that does this as
> well.
>
> Eliot Muir <[EMAIL PROTECTED]> on 22/04/99 00:22:47
>
> Please respond to [EMAIL PROTECTED]
>
> To: Multiple recipients of list delphi
<[EMAIL PROTECTED]>
> cc: (bcc: Peter Jones/Logistics&Information
> Technology/Christchurch/Foodstuffs)
> Subject: Re: [DUG]: How thin the client will be?
>
> Call me a conservative....but why bother with all
these
> proprietary networking stuff? Bound data
> type controls are renowned for making unscalable
applications - the
> little bit of time saved in throwing apps together is
usually absorbed in
> the
> maintenance and slow performance that these
complicated technologies
> result in - especially when they don't work.
>
> DCOM and CORBA etc. don't achieve what they are
supposed to - which is
> transparent operation of applications over networks.
I haven't used MIDAS
> to
> be
> honest but I bet it's not the magic panacea that the
spec sheet describes.
>
> The best approach is also the simplest. Implement
your own simple
> client-server library
> based on on straight TCP/IP or maybe RPC, stream over
some type of hash
> table
> object with a
> version numbering scheme, and get your server to
decipher the calls and
> talk to
> the
> database.
>
> The advantages are that it's transparent - you know
exactly when and what
> data
> is being
> sent across the network. It's easy to debug, you have
complete control so
> it's
> easy to optimise
> - you don't have to spend heaps of time evaluating
crap third party
> products
> which don't work.
> And lastly no license fees or danger of your
client-server architecture
> becoming obsolete if
> the product you used gets dumped or the company which
makes it goes under.
>
> Yanbo Li wrote:
>
> > Thanks Nic, dbOverNet licence sounds much cheaper
than Midia.
> > I will contact with them.
> > I've already developed a Midas prototype. But the
licence is too
> > expensive, we have to get rid of it.
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Nic
Wise
> > Sent: Wednesday, April 21, 1999
9:23 AM
> > To: Multiple recipients of list
delphi
> > Subject: Re: [DUG]: How thin
the client will be?
> >
> > have you thought about using
dbOverNet?
> > www.dbovernet.com - same idea as MIDAS (which, IMO,
is your best option,
> > tho it IS expensive), but I'm guessing their cost
structure is a little
> > different :)
> > N
> > Yanbo Li wrote:
> > >
> > > Thanks, Your information
is very helpful.
> > >
> > > Cheers
> > > Yanbo
> > >
> > >
-----Original Message-----
> > > From:
> > [EMAIL PROTECTED]
> > >
[mailto:[EMAIL PROTECTED]] On Behalf
> > Of
> > > [EMAIL PROTECTED]
> > > Sent:
Tuesday, April 20, 1999
> > 2:14 PM
> > > To:
Multiple recipients of
> > list delphi
> > > Subject:
RE: [DUG]: How
> > thin the client will be?
> > >
> > > IB Objects
and FIB components
> > rep[lace the BDE for
> > > Interbase but you still
> > > need the
IB Client.
> > >
> > > DCOM is
not necessarily
> > Windows only... but if you can
> > > find anyone who nows
> > > how to get
DCOM for Mac or
> > DCOM or Solaris working then
> > > you are doing well.
> > > It's hard
enough to get it
> > going on NT!
> > >
> > > You could
use JBuilder and
> > Corba for the server end
> > > too...
> > >
> > > Peter
Harrison IT
> > <[EMAIL PROTECTED]> on 20/04/99
> > > 14:45:54
> > >
> > > Please
respond to
> > [EMAIL PROTECTED]
> > >
> > > To:
Multiple recipients of
> > list delphi
> > > <[EMAIL PROTECTED]>
> > > cc:
(bcc: Peter
> > Jones/Logistics&Information
> > >
> > Technology/Christchurch/Foodstuffs)
> > > Subject:
RE: [DUG]: How
> > thin the client will be?
> > >
> > > Using
standard Delphi the
> > TQuery requires the BDE to be
> > > installed, along
> > > with the
database client of
> > choice. You don't mention
> > > the database
> > > type, so
lets assume we are
> > talking Interbase. You will
> > > need to install
> > > the
Interbase Client on the
> > client machines, the BDE,
> > > and your
> > >
application.
> > >
> > > This is
not 'thin' client in
> > the least.
> > >
> > > If you
want to use Interbase
> > you havn't got much choice
> > > about any of
> > > this,
except that you might go
> > with a product which
> > > replaces the BDE
> > > with a
driver specifically for
> > Interbase eliminating the
> > > need for the
> > > BDE (do
these exist?)
> > >
> > > If you
want to go with File
> > Based Databases, such as
> > > dBASE, you can
> > > probably
eliminate the
> > database client and bde, and have
> > > a single app,
> > > and
perhaps a DLL or two.
> > 'Apollo' is an example
> > > product for this
> > > approach.
> > >
> > > Besides
the n tier stuff there
> > isn't much alternative.
> > > You could always
> > > start
writing DCOM interfaces
> > - conceivable by really
> > > ugly - and Windows
> > > dependant.
> > >
> > > Good
luck...
> > >
> > >
-----Original Message-----
> > > From:
Yanbo Li
> > [mailto:[EMAIL PROTECTED]]
> > > Sent:
Tuesday, April 20, 1999
> > 1:10 PM
> > > To:
Multiple recipients of
> > list delphi
> > > Subject:
[DUG]: How thin
> > the client will be?
> > >
> > > Many
thanks in advance.
> > > I need to
know how thin the
> > application will be if I
> > > only use TQuery
> > > and
TDatabase to connect to
> > remote server. If the app is
> > > still very fat,
> > > I have to
manage to write my
> > own driver which I am not
> > > found of. Please
> > > do not
suggest me to use
> > TClientDataSet and 3tier
> > > technology.
> > >
> > >
> >
------------------------------------------------------------------------
> > > ---
> > > New
Zealand Delphi Users
> > group - Delphi List -
> > > [EMAIL PROTECTED]
> > >
Website:
> > http://www.delphi.org.nz
> > >
> > >
> >
------------------------------------------------------------------------
> > > ---
> > > New
Zealand Delphi Users
> > group - Delphi List -
> > > [EMAIL PROTECTED]
> > >
Website:
> > http://www.delphi.org.nz
> > >
> > >
> >
------------------------------------------------------------------------
> > ---
> > > New Zealand Delphi
Users group - Delphi
> > List - [EMAIL PROTECTED]
> > > Website:
> > http://www.delphi.org.nz
> >
> >
------------------------------------------------------------------------
> > ---
> > New Zealand Delphi Users
group - Delphi List -
> > [EMAIL PROTECTED]
> > Website:
http://www.delphi.org.nz
> >
> >
>
------------------------------------------------------------------------
---
> > New Zealand Delphi Users group - Delphi List -
[EMAIL PROTECTED]
> > Website: http://www.delphi.org.nz
>
>
------------------------------------------------------------------------
---
> New Zealand Delphi Users group - Delphi List -
[EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
>
>
------------------------------------------------------------------------
---
> New Zealand Delphi Users group - Delphi List -
[EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
------------------------------------------------------------------------
---
New Zealand Delphi Users group - Delphi List -
[EMAIL PROTECTED]
Website: http://www.delphi.org.nz
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
