The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

best approach for app over slow link?

The application is a network monitoring and control interface.

The current implementation is a java applet. It's too slow over a wan. Plus, clients want access over their mobile phones.

Some possibilities come to mind:
1. html/ajax. I don't know of ajax support on mobile phones however.
2. java web start. I don't know if it really helps the wan problem. How do you provide that instant-on perception to people when all this crap has to download?
3. A more complex architecture where users talk to a server side app that remotely bridges over the wan to the "real" server.

Any thoughts on what might work?
son of parnas
Saturday, December 24, 2005
 
 
How elaborate are the controls?

If you can monitor and "control" the network using email or SMS, that's probably the most universal way to go.  Keep in mind that for security reasons, most people do not attempt to "control" their servers through cell phones, and web interfaces typically are limited to things like restarting Tomcat.  (You don't have to waste time securing something if it doesn't exist to begin with.)

As much as we bitch and whine about it - the convention is to send an email, a page, or whatever describing the state of the network to the technician, and if there's a problem, he either comes into the office or SSH/VPN into the boxes.

Err...  I just realized that this advice isn't all that helpful - so I will say that you probably should go back to the client and try to discourage them from being able to "just press a few buttons on their cell phone while sipping a mocha latte at their local Starbucks."

If you're stuck with it, try to get away from the whole web paradigm of rendered pages.  Use a basic command line/menu interface via SSH approach where the client can select menu entries (or thumb in commands), and the info is sent as encrypted text.
Anonymous Coward
Saturday, December 24, 2005
 
 
I guess the question is: what's too slow? Can you use asynchronous background process to keep the data up to date? Can you compress the data? Can you preprocess data on the server instead of launching lengthy processes in real-time?

A WAN client can't be expected to function like a LAN one. Can the UI be changed so that the user's expectations are more appropriate for the retrieval times?

I've developed a Java WAN client that seems similar. It used a 16kps connection. It used a Windows CE machine. It even used SOAP! And the user never perceived slowness because the UI managed the user's expectations appropriately.
slava Send private email
Tuesday, December 27, 2005
 
 
Maybe email/sms for realtime event notification and an html app for users to browse on notification.

The base use scenario is:
1) Tech receives notification email.
2) Based on the notification info, tech fixes the problem.
3) Tech updates the system status through the web app.

Maybe you can send multiple notifications per email (send email out only a few times / hour). Ideally you would have in the message all the information needed to fix the problem. That helps with out of coverage scenarios, plus it means less browsing/traffic.

On the html app side the real time is hidden by the web server. Users get to see the network status at the time of their request. That should be less traffic and 0 client installation).

You could probably use bugzilla for a proof of concept :)

As an alternative you may use email/sms to drive an application on the client side. But that feels like more code and more traffic than the first alternative. Plus it requires client side installation (which makes things fairly complex).
Dino Send private email
Tuesday, January 03, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz