Andrew po-jung Ho wrote:
>
>
> In environments such as the "disconnected" client (e.g. Palm Pilot)
>
Here is where the Palm (and other such smart devices)
paradigm run afoul of the web application server model. To
recap, a web application server (Zope, PHP, Perl, Java, ASP,
whatever) uses the browser to display a GUI which interacts
with application logic on the server. If your device must
run disconnected from the net, which all devices must assume
will happen sometime, then the GUI becomes disconnected from
the application logic. To use the device while disconnected
you must load both a browser and the application server on
the device and then do data synchronization when the network
next becomes available.
This is 1) awkward and 2) requires too much on the small
device.
So, if one is using a web application server for
development, then you must accept that when the device is
disconnected, there is no application available!
If this is unacceptable to the intended use of the
device, another paradigm should be used. I believe that is
roaming, mobile code. The exact world java was intended to
service (and failed at!). Since java has become such a
success on the server side, I have neglected the client
side issues that caused the original failure. Let me
recount them and see where we are:
No standard java platform - The advent of java2
(j2se1.3.x and j2me) and Microsoft's abandonment of java has
stabilized platform differences.
applet's took to long to download - the advent of jnlp (
http://java.sun.com/products/javawebstart/docs/developersguide.html
)
provides incremental version control and cacheing
capabilities, thus replacing applets with applications.
data synchronization - for now the Palm model seems
dominant, but I expect that agent technology or something
like JavaSpaces to become more widespread. (
http://java.sun.com/products/javaspaces/faqs/jsfaq.html ).
So, in the device world, I am coming to the conclusion that
client side code with a data synchronization layer is a
viable solution.
