[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ossig] Quasar Accounting Software for Linux
- To: ossig@xxxxxxxxxxx
- Subject: Re: [ossig] Quasar Accounting Software for Linux
- From: Vincent Lee <leehongfay@xxxxxxxxx>
- Date: Mon, 21 Feb 2005 08:18:12 +0000 (GMT)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
- DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=1q7MNcqSDHhbPzkUEuwgd3MhFSI2Vf6AgAtelSPb2dIDGBkVup79IUBBlWMjYvPpjRgymbZTH2YP2faLYfhKYvV/ODyFE05CCsLhHLj6VSfq4Wvpu9Xjl/dYOyqG9McMUAQFzt3flEdAckSyI5k9spLmWBaHGjxPoHPD+QDxpUo= ;
- In-Reply-To: <421985BF.5040107@ameba6.com>
- Reply-To: ossig@xxxxxxxxxxx
- Sender: owner-ossig@xxxxxxxxxxx
I suppose, we are looking at which is the optimum point for the following
model:
Database <--- A ----> processing <--- B ---> presentation
For thick client application, processing is done at the client side, so there
are a lot of data to be transmitted at point A.
For thin client application, processing is done at the server side, only
processed data is sent to the presentation layer.
The only way to minimize transmission at A using thick client application is to
have a lot of "stored procedures" in database, otherwise the overhead of
transmitting the data to be processed at client side (A) could be expensive.
For thin client application, J2EE solves the problem with Session Bean. If we
have to design the patterns ourselves ("easier said than done")... but we don't
have to re-invent the wheel, the solutions are out-there, just need to look
hard enough :-)...
--- Ditesh <ditesh@ameba6.com> wrote:
> Vincent Lee wrote:
>
> >surprisingly, web-based front end is actually faster.. for example, if I
> were
> >to enter a field to look for a customer, there are 10 thousand records, most
> >thick client app actually search for all records on each "key stroke", and
> if
> >the user were to use 6 characters to locate the record,
> >
> >
>
> Not necessarily true. My latest web app searches on key stroke events so
> you could have the same problem if problem the problem was not foreseen.
> However, if you page your recordset and display, then you'd always be
> retrieving only N records at any point. Throw in some intelligence in
> your javascript, some caching on the server end (admittedly easier said
> than done), compression/decompression and you've eliminated a chunk of
> the problem.
>
> I think it boils down to having good use-cases and aggresively testing
> the app.
>
> Ditesh
>
>
> ---------------------------------------------------------
> To unsubscribe: send mail to ossig-request@mncc.com.my
> with "unsubscribe ossig" in the body of the message
>
>
=====
-----------------------------------------------------------------
Wavelet Technology - Your Open Source Software Solutions Provider
-----------------------------------------------------------------
Unit C-902 Penthouse, Kelana Square
17, Jalan SS7/26, Kelana Jaya
Petaling Jaya, Selangor 47301
Malaysia.
Tel: 012-6018838
-----------------------------------------------------------------
CONFIDENTIAL NOTE:
The information contained in this email is intended only for the use of the individual or entity named above and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete the mail.
Thank you.
---------------------------------------------------------
To unsubscribe: send mail to ossig-request@mncc.com.my
with "unsubscribe ossig" in the body of the message