Once you've done a library like this once you can reuse it for all your
projects - just enhancing it as you go. It's a capital investment you put into
your own career as a developer. If a company doesn't have an infrastructure
already in place you can bring your own libraries. I prefer this approach to
the other one which is constantly having to re-invent the wheel as one learns
the next wizz bang approach.
You'll find also that there are some really top notch developers like Ian
Farquharson and another mate of his called Lynn Prentice that are only too
happy to give you the libraries they've developed over time - they usually way
better than what's available commercially.
Of course you can't expect to get support in the same way - but you've got the
source code. The main point is to develop your own real understanding - you're
investing in your own mindset - it much more worthwhile than learning stuff
like DCOM. When something goes wrong it's usually easier to figure out a
system you have code for than trying to decipher something which is in binary
I can probably throw together the basics of what I've described and put the
source code on our companies website for free if people want it (not right this
week - I have to do my tax return...)
Cheers,
Eliot
P.S. Glad you liked the book!
--
Eliot Muir, Managing Director iNTERFACEWARE
mailto:[EMAIL PROTECTED]
Voice 64-9-5202077 http://www.interfaceware.com
Makers of HL7 Chameleon
"Program to the iNTERFACE not the the implementation"
========================================
Tony Blomfield wrote:
> 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
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
