On Tuesday 23 September 2003 15:17, Winelfred G. Pasamba wrote:
> what's the advantage?
i've wondered the same thing. a web based POS would be a curiosity,
i don't see it becoming a viable alternative to a text or windows based
native app unless major issues with HTTP interactivity are solved. or
it uses javascript heavily to provide the interactivity that you expect
in a native app.
> i mean aside from being easier to develop. diba a browser is usually
>bigger than an X application? plus httpd & php overhead.
i'd ignore overhead for now (you can always buy more hardware if
the performance gain is worthwhile), i'm wondering about things like:
A. incremental search on lookup tables
e.g., we have a large table of available item numbers, we can
force the user to type the number in directly [most POS systems
i've seen do this if the barcode scanner doesn't work] , or they
can select from a list [bad idea if there are a lot of numbers],
or we let them type, and we progressively narrow the list of
items shown to only those that match what they've typed
so far, they can then use cursor keys or ENTER to select
if the list has narrowed to a manageable number [optimal].
javascript might be able to do the job, but that's going to be
some terrible programming. and it has to be generic so it
can be reduced.
B. hotkeys for various functions, maybe even hotkeys for very common
items (e.g., at a fastfood restaurant you might hotkey all the items,
there aren't many and hotkeys are a viable option). javascript
again, i guess.
C. session management and authentication for supervisor approval,
session cleanup:
sessions are a problem. particularly for short or one time things
like things that require supervisor approvals (discounts that
the supervisor has to sign off on or swipe their id card for).
some browsers will keep session data around until the browser
exits or a timeout expires. unless you have fine control of how
to expire sessions on the browser as well as on the server,
there might be issues of replaying transactions or replaying
authentication credentials used in a previous transaction for
a new transaction that is *not* validly authorized by the
supervisor (or whomever).
generally session issues can be worked around and solved,
particularly if you standardize on a browser (and of course, in
a POS situation, the browser would certainly be standard),
but it's a pain.
i might be able to come up with some more, but those few are off the
top of my head. anyone who has programmed a web based system
that should have been a regular GUI program will know what the
limitations of web based programs are.
tiger
--
Gerald Timothy Quimpo gquimpo*hotmail.com tiger*sni*ph
http://bopolissimus.sni.ph
Public Key: "gpg --keyserver pgp.mit.edu --recv-keys 672F4C78"
Doveryai no proveryai.
--
Philippine Linux Users' Group (PLUG) Mailing List
[EMAIL PROTECTED] (#PLUG @ irc.free.net.ph)
Official Website: http://plug.linux.org.ph
Searchable Archives: http://marc.free.net.ph
.
To leave, go to http://lists.q-linux.com/mailman/listinfo/plug
.
Are you a Linux newbie? To join the newbie list, go to
http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie
