[EMAIL PROTECTED] writes:
> In response to Mike's post...
>
> I know exactly where you're coming from and you are right a web based
> solution is the simplest and would be the fastest to develop and
> rollout etc. but..
>
> The cost is in the data, in the uk you get charged for the amount of
> data you send/receive by GPRS and this data you are paying for would
> ideally be useful data and not the HTML to present it.
I'll take your word for it that you don't have GPRS providers in the
UK that have an all-you-can eat plan. They all do in the US.
However, HTML doesn't *have* to be the bloated crap that seems to be
produced by most designers - more more accurately, by the GUI tools
they use to produce HTML. Used properly, it can be a very sparse
encoding system. Not as good something designed for the data at hand,
and not as good a binary format, but not awful, either.
Further, you may be able to save bandwidth by putting some of the HTML
on the mobile device. For example, the form your field engineers fill
in to note that a job has been done could be kept on the PDA (assuming
it's static), and just opened in the browser, filled in, and
submitted. Palm did this with their PQA technology - a PQA was a set
of HTML files that were "compiled" into a representation their browser
understood.
Finally, if the data bandwidth is really a serious problem, you might
want to look into a solution at a different level. For instance, if
you're using a VPN to get to your internal network, some VPN
technologies include facilities to compress the data traveling across
the network. That will reduce the difference in bandwidth usage
between the various encoding formats you might consider.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
