Terry,
> I'm in the process of writing an app that needs internet
> connectivity to
> download updates for local databases and upload small amounts
> of data to a
> central database. The program needs to be useable off-line,
> so web based
> solutions seem to be out.
Why do you say the web is out? With our web application, you can be using
it one minute, the connection can drop (due to the uncertain nature of
internet connections), and when you get the connection again, just continue
working. No big deal - as long as you design your comms protocol properly.
The other alternative for you, if your app is not too complex, is to have it
run on palm, and hot sync when you need to. We also have a web based app
that works that way - and it works quite well.
> The remote end is likely to be SQL
> Server, if
> that makes a difference.
Database is really a non-issue, as long as you are not using a desktop
database, such as Paradox, dBase or Access. Treat it like a data store,
thats all.
> There are also likely to be many
> (thousands of)
> users.
Web servers are designed to minimise the load on the server, while allowing
many users to use an application. The way this works is, the client makes a
connection to the server, requests for a page (data can be sent on the page
request), gets a page (data is retrieved on the reply) and closes the
connection. This way, you may have a thousand users using your application,
but only a small handful may be connected at any one time. This though,
does pose other problems, eg. recognising who your clients are, but there
are off-the-shelf solutions that address these problems.
> What it looks like to me is that perhaps Midas or dbOvernet
> or similar is
> what I need. The problem I have is that client/server stuff
> of this nature
> is new to me, and I'm trying to decide on the appropriate
> hammer to crack
> this peanut with.
With the 3rd party solution we employ, you write your app as a single
threaded, single user (but multi-user capable) application, and let the
application framework handle the complexity of servicing many users for you.
> I could of course write my own IP solution wrapped around a
> fairly standard
> protocol, but I don't want to get in the way of other
> services running on
> the server (e.g. SMTP/POP3).
This is one possible way, and as long as you pick a port that does not clash
with the standard ones, you ought to be OK. Beware though you might have to
contend with security issues (firewalls and proxies). Also, while this will
give you a customised protocol to use, you will have to develop it from
scratch - it is far better and cheaper to employ a 3rd party solution. Why
reinvent the wheel?
> Maintenance wise, this sounds
> like a bad idea
> to me, but would be devoid of licensing cost and probably
> quite efficient.
If you have a thousand users, paying $500 per server ought not to be an
issue, don't you think? Works out to be $0.50 per user!
> I'm also very cynical about the quality of 3rd party libraries, having
> spent too much time debugging them in the past, so would at
> least get to
> create my own bugs.
All 3rd party library have bugs. However, bear in mind that whatever code
you write to replace 3rd party libraries will also have bugs (fact of life).
With 3rd party libraries, you have the benefit that someone else will fix
the bugs for you (if they don't then it is not worth getting the lib).
Furthermore, most have discussion groups (like this one) where others will
have encountered the bugs and have found workarounds for them. Think
carefully before you decide to build it all yourself. Imagine if you are
building a house - you don't want to have to bake individual bricks, though
some die-hards do.
We use web hub as our application framework. For smaller systems, the
single instance license is *FREE*. For larger systems, you pay server,
*NOT* per seat or per connection or per user. For more information, go to
http://www.href.com, or email me privately. It also scales very well - the
site has a few *VERY* large site examples. The beauty is it scales without
you having to modify your code, ie., one code base can be used to serve
small and large systems! In my previous employment, I used it to deploy a
distributed app that sits on a WAN the size of Queensland!
> I imagine many of you have dealt with systems of this nature
> before, and
> any views/comments/sarcasm would be greatfully received.
What you have to do is to weigh the relative complexities of the solutions
vs their features and how these features fit into the solution you have to
provide. N-tier client / server programming is not easy by any means, but
it is not rocket science either.
Hope this is of help to you.
Regards,
Dennis.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Offtopic List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
